unrarall cleans files if subs rar has extracted cleanly

[loa11]

Uhhh unrarall made me a horror situation, it made huge mess, you need to fix this issue.
Let me explain, lot of scene files have idiotic naming of base rar file and the archived sub file which has the same rar name as the base rar file, inside the *subs.rar.
In that case unrarall would unpack firstly the sub rar which would overwrite the base rar file.
Example:
name of the base rar file rep-13hoursthesecretsoldiers.1080p.bluray.x264.rar
name of the subtitle file rared with the name "rep-13hoursthesecretsoldiers.1080p.bluray.x264-subs.rar" iside of this rar were two files:
rep-13hoursthesecretsoldiers.1080p.bluray.x264.rar and
rep-13hoursthesecretsoldiers.1080p.bluray.x264.idx
rep-13hoursthesecretsoldiers.1080p.bluray.x264.rar has rep-13hoursthesecretsoldiers.1080p.bluray.x264.sub
As you can see
In my case unrarall deleted 244 base rar files which made 30% of my rared HD movies uncompleted.

There are almost 10 scene groups (REPLICA, SPARKS...) which use such naming formatting, most of them use SUB folders but on most private trackers and on most NNTP indexers uploaders decide that SUB folder were not needed and we have because of that this problem.
There are even cases that those scene groups wouldn't use rared subs inside the rared sub.

[delcypher]

@loa11

Uhhh unrarall made me a horror situation, it made huge mess, you need to fix this issue.

I'm sorry unrarall deleted your files unexpectedly. However this is open source. We don't need to do anything. Demanding things get fixed is a great way to go about getting your issues ignored.

However the behavior describe doesn't seem desirable so we should try to fix it. I need to have a chat with @arfoll first though about setting up some basic testing infrastructure so we don't introduce regressions.

[ghost]

lmao

[loa11]

@delcypher I know sorry I was in shock, I didn't demanded I made urgency about serious problem.

https://mega.nz/#!R5V0iQxD!eqey5KB9peZLMYtHVp1SuCL-Y1GugEgznINnTEHbImA
https://mega.nz/#!U4VBCQaK!-c6L0vcNhKrV_Q76f5T_YLtb7XiDbWjnXaRqJCUi6PU
https://mega.nz/#!A9l0hSTK!JDdgNW49990n8DyjiUgo-C95XTBOtseSqkbQVRpkOJ8
https://mega.nz/#!lh1TTAiK!AZNMiOAMVAJi-mmGPqr58OOs9EW2zWUuj2ckfk1hddc
https://mega.nz/#!cgtxgILS!dc8E-bMACXqpQlq7CVIywFfInzwfzuh6QAX0P4Pezp4

These were the example files, one of these "london.has.fallen.2016.1080p.bluray.x264-drones.subs.rar", has acceptable naming and archiving type, other were with the idiotic archiving and naming.

[arfoll]

hi @loa11, thanks for reporting this and apologies it's caused you issues. If I understand the issue, unrarall considers the subs.rar successfully extracted so then removes everything that looks like a rar archive, including your unfinished stuff.

Unfortunately I'm not sure how to best treat the issue, did you have cksfv running? It would possibly have worked (not 100%) but we could definately introduce strict cksfv checking that would fix it. If you run unrarall with --dry what happens?

@delcypher I did create part of a test harness at one point but never completed it, hopefully it's still around somewhere or we can start from scratch.

[loa11]

Most of rared subs had sfv file and almost every rared movie had own sfv set.

Here is the direct example
http://pastebin.com/udTzDqDp
In the mega links there is actual sub rar
If you look inside the sub rar you will see hail.caesar.2016.1080p.bluray.x264-drones.rar and hail.caesar.2016.1080p.bluray.x264-drones.idx
Unrarall would sfv check hail.caesar.2016.1080p.bluray.x264-drones.subs.sfv firstly and after that it would unrar hail.caesar.2016.1080p.bluray.x264-drones.subs.rar which would unpack hail.caesar.2016.1080p.bluray.x264-drones.rar and hail.caesar.2016.1080p.bluray.x264-drones.idx.
It would overwrite original rar base file hail.caesar.2016.1080p.bluray.x264-drones.rar size 97656K with hail.caesar.2016.1080p.bluray.x264-drones.rar size 5737915.
In the case someone decide to use force syntax with unrarall, complete mkv and all the rar files would be destroyed because cleaner would delete all rar files after, but if you don't use force syntax, just the base rar file is overwritten with the wrong sub base file.

I see few possible solutions, one is that unrarall ignores all the rars with naming *subs.rar or that unararall search for *subs.rar and *subs.sfv and to remove them into the Subs folder or as the final solution is that unrarall skips overwriting.

[vesper8]

wasn't this fixed in #40 ?

And it's confusing.. because that PR says it was merged in the last comments.. yet it doesn't appear to have been merged.. is this problem patched or not?

If so then this issue should be closed?