_UNPACK_ directories not being removed after 0.7.17 upgrade

[gnomehole]

Ever since I upgraded to 0.7.17 on Windows 8.1 (previously was working just fine) the system is leaving the _UNPACK_etc. directories (empty) and not removing them. It doesn't seem to be the case for all, but many. They are always empty.

No other system changes have happened so I assume its something with the latest release.

Still functions ok, but very annoying.

[shypike]

Windows has lots of issues with renaming folders.
You can disable the temporary renaming in Config-> Switches.

[FCrane]

I can confirm that bug! It started with v17 and it seems to occur only in the following cases: After downloading Sabnzbd seems to create that _UNPACK directory but if a repair is needed, it starts the repair and afterwards creates a new _UNPACK directory, which is subsequently renamed correctly after successful unpacking. The first _UNPACK directory is left.

Again, this only started with 0.7.17, so it's not a Windows issue but a program bug.

Regards!

[sydlexius]

I can confirm that ever since the RCs this has been an issue for me as well.

[ErikBrown]

Same issue for me. I only noticed it rarely before but I do see it almost for every download with the final 0.7.17 version. And indeed the temporarily folder that is left behind is always empty. I have upgraded my PC to Windows 7 from Windows XP at about the same time that I upgraded to 0.7.17 final, so this could be related.

[shypike]

I'll check.
Windows 7 itself cannot be the cause.

[bluenote]

This would happen to me rarely before 7.17 but now it's happening a really high amount.

[bleomycin]

Just wanted to add this this is happening for me as well, debian 7 64bit. Please let me know if there is anything useful I can provide to help.

[InterClaw]

I don't use the unrar functionality, but I believe I'm suffering from the same bug, so by reporting it might help in finding the cause. This started for me as well in version 0.7.17.

Whatever I download that creates a folder I can't remove this folder. It says I need permission to perform this action - from myself. Even elevated I can't delete it. I tried shutting down SABnzbd and logging out. The only thing that helps is to restart the computer.

Since it's folder related I think this is part of the same bug.

[shypike]

Can you provide a debug log of when this happens?
On the status page you can enable debug logging.
After a download in which the issue occurs, you can download the log file from the Status page.
and email it to [email protected] (please add the URL of this message).

[jt25741]

I confirm this just started happening with my setup with this release, and I am on XP. So it is not any specific version of Windows. Perhaps the new unrar?

[shypike]

Probably not the new unrar.
But it beats me what the cause is.
I will add extra logging to the next test release, so that I get more info.
In the mean time: just disable folder renaming in Config->Switches.

[FCrane]

As I reported before: this seems to occur when Sabnzbd tries to begin unpacking but then needs more blocks for repair. The upnack directory is created, then the repair is processed and afterwared a new unpack directory is created. The first one is not deleted.

[jt25741]

Probably not the new unrar.
But it beats me what the cause is.
I will add extra logging to the next test release, so that I get more info.
In the mean time: just disable folder renaming in Config->Switches.

Thanks ...seems to fix things....at least so far.

[bleomycin]

I'm curious if this has been resolved? Disabling folder renaming breaks nzbdrone so that isn't an option for a lot of us. Thanks!