0.6.0 RC1 - Can't delete oprhaned jobs

[young-einstein]

Hi all,

I've noticed that under Status > Queue Repair, I can't actually delete any orphaned jobs from that page. 

When I click the little X next to a job the page quickly reloads itself, but it doesn't actually remove the job from the list (and it doesn't delete anything from the drive either).  If I just go ahead and delete the folder myself (directly from the disk), then the job disappears from the list as it should.

From what I can see, I don't think that it's a problem with file/folder permissions anywhere.

Clicking the add button works fine, the job reappears in the queue and then disappears from the list, so it's just the delete feature which seems to be broken.

I've got two computers running 0.6.0RC1, one on Ubuntu 10.10 x86 and the other on 11.04 x64.  I've tried the latest version of Firefox and Chrome on each of them, and found the same result every time.

FWIW ... I've noticed this problem has also been present in earlier 0.6 BETAs as well, I just never got around to actually reporting it.

Just let me know if there's any more testing/debugging info that you need.

Thanks,

--David

[shypike]

Just let me know if there's any more testing/debugging info that you need.

It could be that the criteria for showing a folder as orphaned is slightly different from
the criteria used to decide if a folder is deletable.
Are *all* orphans non-deletable?
Can you check which files are in the __admin__ subfolder of the undeletable folder?

[young-einstein]

UPDATE: I think that I've just (partially) figured out what the problem is.

It seems that the delete button DOES actually work, but not when there happens to be another sub-folder inside the one it's trying to delete (even if it's empty).

This happens if I start extracting a rar set while the job is still downloading.  When SABnzbd finishes the job, the folder I was extracting to stays behind in the incomplete folder, and then the job shows up in the orphaned list.

The problem is that I can't delete it because of the (empty) sub-folder which is still present.

This may or may not actually be the intended behaviour, but I'd obviously prefer it if I were still able to delete the folders from that page.

Thanks ...

--David

[shypike]

SABnzbd is very careful not to delete anything it did not create itself.
Therefore only files in the job folder and the __admin__ folder are removed.
So this is intended behaviour.

[young-einstein]

I was afraid you were going to say that, but I can see where you're coming from!

At the very least shouldn't it through up some sort of error/message when that happens though?

[shypike]

Maybe a warning message is in order here.