SABnzbd Forums

Hi,

I've recently downloaded some TTC video lectures which had about 155 RAR files. The postprocessing was set to "+Delete".
Today I checked the completed downloads folder, and it only had 3 files. It seems that SAB somehow deleted everything else and only extract a small amount.

A similar thing happened to another TTC video lecture I downloaded, so I'm not sure what's going on but this is a serious data loss issue.

Here's the log file of that one particular lecture: http://ifile.it/fuonxrv

I'm running SABnzbd 0.6.1 on Win 7 x64.

I think I know why this happens. I've just redownloaded the lecture and tried extracting it myself.

The problem is that the extracted path exceeds 260 characters, so only the files with the short names are extracted (hence the 3 files that I noticed).

For some reason SAB seems to ignore this error, and simply deletes all the RAR files after the "extraction", which leads to serious data loss.

I think it only ignores the error if you tell it to do so.
Normally it compares the expected with the actual files.
There's a "special" setting that disables this check
(unpack_check = 0 in sabnzbd.ini).
That's only needed on systems with filesystems that have
inconsistent handling of accented characters (so normally not Windows).

I haven't touched the .ini file.

This has nothing to do with accented characters. The MAX_PATH on windows is 260 characters, and anything beyond that will give an error.

So what should I do?

Caleb wrote: This has nothing to do with accented characters.

I did not claim that it has, only that there is a special setting for systems that do have problems with it.
Can you check if this is in the sabnzbd.ini file?
unpack_check = 0

Yes, it's set to 0.

That means that SABnzbd will *not* check the results of unrar.
Did you set it to 0 yourself?
Stop SABnzbd, and set it to 1 again (the default).

No, I did not set it myself. In fact, I have only installed SAB a few days ago (completely clean install).

Drat, the default value is now "off".
We probably did that because the check often fails on OS's other than Windows and OSX.
Not really a good idea and we must reconsider this.