[Request] Delete empty folder about unpackerr HOT 19 CLOSED

It's a lot of code to do what you're asking. Checking for an empty folder was not very much new code, so solving the original problem was easy. Unpackerr is an extracting tool. You'll need another solution for empty folders. You can solve this problem may other ways that do not involve more code and potentially more bugs in Unpackerr.

I was wondering, why not verifiy from the download path directly?

It's not available when the delete is issued.

from unpackerr.

Ok, I though it might be saved somewhere and you could have the information. Like we say, asking won't bite ;)

I had already another program doing the cleanup, qbitmanage. But their tool is not very unpacker friendly and it start deleting orphaned file from the torrent folder or even while it's unpacking, or when sonarr is copying them. I tried telling them but they refuse to make check before deleting saying "it's because I'm using unraid bad" and said to try here. I'll simply run a user script in unraid that clear empty folder then. My goal was to build on top of another existing solution simply.

Thanks again for your help!

from unpackerr.

Sounds like you talked to @bakerboy448. Sorry about that experience.

from unpackerr.

The issue described was unpackerr was not cleaning up the extracted files, but Starr imports were slow due to paths that resulted in slow IO intensive copies

ref StuffAnThings/qbit_manage#345

from unpackerr.

problem was qbitmanage cleanup while the torrent is still during import or unpacking. I implemented all fixe you said which fixed the cleanup of _unpackerred folders, but it didn't solve the file being unpacked into the torrent folder getting removed either while unpacking or while importing. A simple Starr check to see if the torrent is still waiting/during import before a cleanup would suffice, but you refuse that stating bad io. So instead of making the program more robust and prevent false positive, you decide to blame performance. That's bad coding my friend, but it's your software so I didn't argue more just like here, I don't argue more and I'll implement my own solution.

Thank you

from unpackerr.

qbm has no communication nor any interaction with starr nor are their any plans to. it is a qbit tool, not a starr tool.

an ideal setup that facilitates hardlinks rather than io intensive copies means the only case where qbm would remove unpacked files as orphaned would be a perfect storm where in roughly the same minute, unpacked files exist; starr has not yet or is refreshing the queue and has not begun the imports - which would be near instant - due to hardlinks or running qbm so frequently it is checking faster than starr can import....again using hardlinks

but that is neither here nor there for further discussion

from unpackerr.

Can you make qbit change the category more slowly and set the delete_delay in unpackerr to maybe 1m? That may solve it.

Basically, get qbit to move the download files after unpackerr cleans up.

from unpackerr.

I don't see where I would set that in qbittorrent? QBittorrent folder management from category is automatic. You set the folder in the saving management window and everything is automated. When a torrent change category, it move it.

As for the *arr program, they don't have a post-import delay, it's just a setting in the qbittorrent client where it says "post-import category".

I tried using qbitmanage to clear out orphaned files but I had to stop using this feature. The cleanup process would start while something is waiting to be imported or being imported (or even extracted) and this would cause error with all *arr apps including unpackerr. I tried asking them to have a check against qbittorrent so it doesn't check for orphaned file in a known torrent folder but they refused saying I don't use unraid the "right way"....

from unpackerr.

Your request seems reasonable, and I'll see if we can do that. re: delete folder if it's empty after deleting extracted item.

from unpackerr.

Hello @nodiaque,

Please grab unstable and let me know if that solves your problem. In docker it's golift/unpackerr:unstable otherwise head over here. This is the entire change: 23eb84e

from unpackerr.

Ok I installed it, I'll get a torrent and check if it work. Thanks!

from unpackerr.

Once you tell me it works, I'll cut a new release.

from unpackerr.

Sorry for my late reply, took a long time before I get a packed torrent.

It seems to work great but I found one caveat which I don't know how we can fix it, maybe with information from sonarr/radarr/qbittorrent about the save folder.

Just had a torrent that had multiple rar file in different subfolder, like:
the package s01

• s01e01
  -- s01e01.r01, r02.... rar
• s01e02
  -- s01e02.rar

etc.

When the delete is ran, it delete all s01e0x folder which is very good, but then the torrent folder at the root is kept (the package s01).

Unsure if I'm clear?

from unpackerr.

Unsure if I'm clear?

Why try to be clear when you can share a screenshot?

Are you describing a torrent with more than 1 season in it? Sonarr does not even support those.

from unpackerr.

I didn't though about screenshot, sorry. No it's a 1 torrent for a whole season and each episode is in it's own folder, compress in a different rar. At the end, it properly deleted each episode folder but the base folder remained

from unpackerr.

Gotcha, I don't think this will be something Unpackerr can fix for you. The risk of the app crawling too high up and deleting your /downloads directory (because it was empty) becomes real when I try to solve this. You could look into packer executing a script when it finishes, then you can control what to delete.

from unpackerr.

I was wondering, why not verifiy from the download path directly? The torrent normally have a download path that you currently use to search for rar. If you store it, you can use it later to do a recursive delete from there? This why you won't risk getting the download folder. An idea like that.

from unpackerr.

So if a starr app is faulty, boom qbitmanager will clear it. QBM is set to run each 30 minutes, but when you download, the 30 minutes mark can happen at anytime. Hardlink won't solve the problem where unpacker is extracting the file. Since you don't want to communicate with Starr, you still have already a communication with qbittorrent. Something could be very easily added to check if the torrent is still in a download category since it already know which category are download and library and skip these. You already have this information for many other check thus it's nothing to do.

But yeah, I'll just make my own cleanup script instead of trying to improve imperfect solution that as no fail safe and think that everyone should have only 1 way of doing things as a holy grail. BTW, "my" way of doing thing is as popular if not more then trash way, and there's other way too.

edit: I would like to thanks @davidnewhall for his help, the provided fix solved 99% of problems and the fact that the remaining would give a marging of failure where all downloads folder is delete is an understanding reason why not to go further.

from unpackerr.