Problems with really long file names

[Jere_Tristan]

I think I have stumbled upon something here.
If sab finds like reaaly long filenames, and the defaults are set at RUD, it will report;

Code: Select all

Stage Download
    [Time-Taken]: 1 hour 30 minutes 42 seconds 
    [Avg-Speed]: 218kB/s

	
		

Stage Par2
    [PAR-INFO] xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: => Unknown error while running par2_repair, see logfile

	
		

Stage Unrar
    [UNPACK]: => No post-processing because of failed verification 

with xxx being the filename. It will then presumably delete all files, and make a [failed]xxxx folder (empty, of course).
I have been able to replicate the error every time with the same nzb's, using Windows.
Alt-Binz downloads the file without problems.


The log file is like 5MB, si I wouldn't know what to look for in there. If you nead, I'll pm u the real filename.

[shypike]

Different implementations come with different problems.
You could try to use a shorter NZB name, because that name adds to the size of the path.

Can you send the NZB and the logfile to bugs at sabnzbd.org ?

[Jere_Tristan]

Sent.

[Jere_Tristan]

I have to note that the files are created in the default download folder, which on my system is C:\users\XXX\Documents\Downloads\complete.

Alt.binz downloads them to C:\users\XXX\Documents\Downloads\.

[switch]

Try downloading to a fixed path (such as C:\Downloads) rather than a relative one. Relative paths have a limit of 255 characters, where as fixed paths have a limit of ~30k characters.

I'm not sure how it is hitting the limit as we tend to convert paths to an absolute (fixed) path; it could be a python issue or a par2 issue. The downloads worked fine for me using a fixed path of small length.

EDIT: It seems when using the windows API it only allows paths of 260 characters in length, and only 32k characters when using unicode versions of specific functions http://msdn.microsoft.com/en-us/library/aa365247.aspx