Alt.Binz forum
Alt.Binz (English) => Help => Topic started by: Gnafron on October 26, 2007, 02:28:25 pm
-
hello,
within the 2.6 I got the following problem...
Downloading Ok
and when it starts to decode... it's stay to decode for a while... :cry:
the history shows the message " too long file name "...
here is the name: (I replace the real letters by false :D )
"[XCT].xxxxxx.yyyy.uu.xxxx.(nnn.nnnnnn.mmmmmmmmm).
[xxxxx.bb-ccc{Fr-Eng}.Subs{Fr-Eng}.Chaps.Covers].-xxxxxxxxxx.fr.st-.part.sfv" [01/36]
is that too long?
directories were
e:\dwld\undone\....
I solved the problem by finding same files but with other names (shorter of course...) :?
thks for your help
-
to long file name means the complete path is too long.
do you have subfolders active? then try not to use them
-
thank you cr4zyfr4g
"crazy frog"? beware we, in france are frog eater :D
what is the longuest name we could have?
my complete name with subfolder were (as I wrote) :
e:\dwld\undone\[XCT].xxxxxx.yyyy.uu.xxxx.(nnn.nnnnnn.mmmmmmmmm).
[xxxxx.bb-ccc{Fr-Eng}.Subs{Fr-Eng}.Chaps.Covers].-xxxxxxxxxx.fr.st-.part.sfv
it was certainly too long , but of what?
wwwhat's the maximum length?
tnks :D
-
I didn't have any problems decoding those with same path you used. Are you sure you didn't used NZB name as subfolder option?
-
it was certainly too long , but of what?
wwwhat's the maximum length?
tnks :D
For Windows, the maximum (non-UNC) I believe is 255, of which the path portion must be less than 248 characters. Someone less lazy than me can look it up. :)
-Hecks
-
Have also seen this issue. Allthough for me, after a while, ABZ craches! :-/
Will post a screendump + sample.nzb in private, Rdl.
-
All that is known issue. It could be detected before raising error. The real question is what to do in that case? Dump files to c:\ ? :)
-
Truncate the name of containing folder? i.e. last part of path, longnzb~1/filename.avi?
-Hecks
-
Either do as Hecks says, or simply truncate the filename.
As for the example you got from me, the filename was about 240 chars (as far as I remember). Have no clue why the person had uploaded such large filename, which I find rather stupid.
Anyway, as you could see on the screenshot, it would be nice with at least some "limit" on repeating the error - got huuuge logfiles, due to that ;-) + the crashing part
-
Subfolders shouldn't need to be disabled. It's true that people shouldn't post things with names that are stupidly long, but it happens quite a lot, and the program should be equipped to handle it properly.
This is a pretty serious problem, and fairly likely to happen, especially with the long default download path (C:\Program Files\AltBinz\download) so IMO it should be fixed ASAP.
I talked in IRC and got a few pointers from Hecks:
Check your log, if it's too large to open, try this: http://baremetalsoft.com/baretail/
You can use this program in C:\Program Files\AltBinz\temp to decode the files: http://www.celebritypwn.com/altbinz/ManYencDecode.rar (you should probably have altbinz closed)
Hope this helps someone.
-
A simple workaround while we wait for the check to be implemented is to change the NZB filename to something shorter as you import it.
P.S. As a sidenote, I've been using Alt.Binz for over a year and have never once experienced this problem.