Bug when decompressing with password

[kouze]

Hi,

I already noticed this issue few times: sometimes, with no real reason, the unrar with password fails with a CRC mismatch! issue. Result: all .rar are getting removed (normally the process shoult NOT delete them)

Please note that the downloaded rars are correct and unrared perfectly using the same command-line than in sabnzbd

I guess there is an issue somewhere, but the issue is not on the password nor on the downloaded files

See here the content of the log in debug: http://pastebin.com/SBYagete

thanks

[shypike]

The CRC errors that you see are produced by SABnzbd's own RAR reader:

Code: Select all

DEBUG::[rarfile:324] CRC mismatch! ofs =20

The unrar tool itself runs OK and as far as I can see it extracts the file properly.
The worst that can happen is that SABnzbd will not check whether all files are present after the unrar.
Because that's what the RAR parser is used for.

Possibly it's a more recent rar format that SABnzbd cannot read or a CRC error in a record that isn't really needed.
Can you email this NZB to [email protected] ?
(Please add the URL of this message.)

[kouze]

It's done.

The rar have been generated using:

Code: Select all

RAR 4.20   Copyright (c) 1993-2012 Alexander Roshal   9 Jun 2012
Trial version             Type RAR -? for help

on linux (ubuntu)

Thanks

[shypike]

Got your data, but (apart from the CRC debug message) did post processing succeed?

[shypike]

The explanation is rather simple.
You chose to encrypt the file names as well (normally only the content is encrypted).
Subsequently, SABnzbd's simple RAR parser cannot read the names, because it doesn't support passwords.
The only consequence is that it will not check after unrar, whether all files are there.
Simply because it has no list of names.

[kouze]

I got your response by mail.
In fact I did not get the issue with the first .nzb filename I sent to you (I renamed the .nzb file). SAB is unraring the files properly.
But if you use the same .nzb (so same content) with the filename found in the second mail, SAB will fail.

Actually I understand the issue about the encrypted header. But I don't think the issue is coming from there, as this issue is not systematic (working fine for more than 9 of 10 cases)

[shypike]

But if you use the same .nzb (so same content) with the filename found in the second mail, SAB will fail.

It doesn't fail for me in either case.
Your log doesn't show a problem either.
The debug messages telling you about CRC errors can be ignored, they are not important.

Maybe if you're on Windows, things go wrong because your total path names are too long.
That's, however, an entirely other matter.

[kouze]

Oh, you may be right with the total path name length. I'll check that (I sent to you another mail)
and I'm on windows

[shypike]

Looked into it.
SABnzbd indeed doesn't check the "Cannot create" error that unrar produces.
Because of the encryption, the normal after-unpack check cannot be done.
This is very unfortunate, because you'll loose the files.
The next release will detect this error and report it.
It won't solve the path length problem, but at least you know what's going on.

Thanks for reporting.

[kouze]

Good news shypike.
I don't know why the unrar command is failing, as explained doing it manually the files are correctly unpacked, but it will give more information.

Thanks !

[shypike]

[quote="kouze"I don't know why the unrar command is failing, as explained doing it manually the files are correctly unpacked, but it will give more information.
[/quote]
It fails because SABnzbd doesn't change the current directory.
Your manual run probably runs from the folder where the RAR files are.

Anyway, when we have the Unicode version of SABnzbd ready, we can finally tackle this problem too.