auto-unrar file names incomplete

[RayMark]

6.50B2 and older

If I set the UnRar folder to something like this:

O:\NNTP\$(GOG)\$(GROUP)\$(SUBJECT)\UNRARED\$(FILENAME)\

then unrarred files sometimes have incomplete names - only the last part of the expected file name.

I think that it might be an issue with some windows path length limitation and I don't know if Newsbin could handle it any better.
Without such a stupid long path - no such problems.

.............................................
i7-3770K, Windows 8 x64, 32 GB RAM

[Quade]

It will strip the names down if it has to. So, yes this is a path length problem.

[RayMark]

Actually, it is a bug in NewsBin, I think:

It seems to be truncating the names (also) unnecessarily:
I am able to rename the resulting files to correct full names (without moving them out of those folders with long names) - successfully.
Afterwards those files can be opened from FAR without problems. So that indicates that they were truncated without any need.
For sure, there are also cases when the path/file names are really too long. But not always. NewsBin is too eager to truncate. Or it uses some temporary names when extracting and those temporary names are even longer and causes this unnecessary truncation to occur.

Another issue: sometimes, when unrarring a rar with subfolders inside, NewsBin places files not in their correct folders but takes them out from their folders and places them in the root, sometimes it takes out even some inner subfolders out, it seems. The initial folder structure of the rar archive is completely screwed up.
It, again, happens when NewsBin things that path/file names are too long, but again, not always when they really are.

[Quade]

O:\NNTP\$(GOG)\$(GROUP)\$(SUBJECT)\UNRARED\$(FILENAME)\

What you're basically saying is to ignore this problem. 'cause that's what I'm going to do. I can make paths longer than 255 bytes but, I choose not to because explorer can't handle them. I choose not to run the path up to exactly max length.

Sounds to me like you need to use a shorter unrar path and then use the scripting interface to move the files to any folder you want.

[RayMark]

Ok, clear - now I know you impose your own path length restrictions.

I think, NTFS allows 32K lenth, but windows - only 260 characters.
I wonder, how many characters FAR supports (FAR is basically an OS within an OS for me, I almost never leave FAR)
Because I noticed that sometimes a filename is too long for Far but still not too long for windows explorer.
Your imposed restriction perhaps ensures that Far can always handle those files.

[duckegg]

I have similar issues too

my set up is as follows :F:\NEWS\$(GROUP)\

the file that show up in by explorer is 255 characters
s.12.04.04.philip.princes.I.Want.To.Ride.My.Bicycle.vid.720p.WMV-abc_city_www.city.ag_sponsoredbywww.ssl-news.info_[22_25]-_peddlers.12.04.04.philip.princes.I.Want.To.Ride.My.Bicycle.vid.720p.WMV-abc.part71_-123,45MB-yEnc.nb2

So the person saved this length of file up to the server then? or does Newsbin somehow pars the name, effectively doubling the size, then dispose of the unparsed half? or does the sever pars the name.

[Quade]

That's not the actual filename. That's a temporary filename used as Newsbin is putting the file together. The actual filename is probably just the tail end section.

An NB2 files gets renamed into the real filename when the file completes.

[aliceten]

You can use Long Path Tool as well, it can be helpful to such problems...

[Calahan]

What you're basically saying is to ignore this problem. 'cause that's what I'm going to do. I can make paths longer than 255 bytes but, I choose not to because explorer can't handle them. I choose not to run the path up to exactly max length.

Sounds to me like you need to use a shorter unrar path and then use the scripting interface to move the files to any folder you want.

One of the benefits of short paths is that there is a 250ish character total limit on filename + path length. If you then have folders inside the rar and longish filenames, you might run into the limit. What Newsbin does is actually strip the path down if it needs to in order for the filenames to work.

Hello Quade,

I use Newsbin for some time now and I have those path/filename problems frequently.
I think, using a shorter unrar path or other ideas as scripts are only a short solution because they are no safe solutions.
It can happen every time again with a path/filename combination which is too long again.

I have tried to unrar the same rar files at the same position (were Newsbin was unraring them), with Winrar 5 and with
Total Commander and both Programs have worked as Newsbin should have.

I saw that Winrar used the "trick" of using the windows short names for folders when the path/filename length got too long.
So all single folder names as "This is a long folder name" are accessed as "THISIS~1" (dir command with /x) and
only the last name is in long format. (For readability, I think.)

Don't know how Total Commander unrars the files without problems but it does.
By the way, Windows Explorer is also able to access all those files with too long names.
Maybe it's accessing the files the same way as Winrar does.

I'm not happy with that problem, because I had to disable the "Delete RARs and PARS on successfulUnRAR" option.
Now I have to delete the rar files for all downloads manually after checking if there were problems.

Maybe your unrar part is not self-written (maybe from another source) and you don't want to or can't change the current behavior.
I think there are other possibilities that would make me (and maybe other) happy

If rar packed folders and files can not be expanded as they are packed, it should be handled as an error and
all the downloaded rar files should not be deleted. So I could check the "Delete RARs and PARS on successfulUnRAR" option again
and if that path/filename length problem is happening again, I could expand those files manually with another program.

And I also think that it's not correct to change the folder/filename structure leaving files at other places or don't
create folders at all... I think a tool which expands rar files should expand them just as they are packed in the rar or in other
words, in the same structure as when they were packed.

So I think there should be at least an option to disable this "strip the path down if it needs to in order for the filenames to work" part.
If it's not possible to create a folder or a file because the path and filename length is too long, it should be treated as an error
and the rar files should not be deleted. (I don't think it has to to be a selectable option too, because if a folder or a file cannot be
created or written, it should always be handled as an error. But if it would be an option to check or uncheck, I would be happy too.)

Maybe you can think about it (again).

Kind Regards
Calahan

[Calahan]

One week is over and still no comment.
Should I have started a new thread?
Do I have to buy another newsreader?
Questions over questions

But I don't want to have to buy another newreader (again).

English is not my first language, so you maybe didn't understand what I have written before. I will try again:

The daily work to check and delete the rars and pars when the dowload is complete, is more and more time consuming.
My download path is short, it's "X:\Downloads"
To find the downloaded posts, I added: "\$(GROUP)\$(NZBFILE)\"
I think both are needed to find the posts and to know what was downloaded.

Many rar files contain long folder names often identical to the NZB file name.
Which double the length, but I have no control over the length of foldernames in rars.

When rar files were unpacked, all files and folders in the rar have to be at the same position and with the same names when they were packed or all files are unusable.
That means to download several GB again and again or to turn off the auto-unrar which leads to much manual work as I wrote before.

I really don't understand why an unrar feature is corrupting folder and/or filenames or the structure of the folders.
If files and folders can not be created because the path/filename is too long the unrar process should come back with an error.
Then the standard could be, to always unrar and after SUCCESSFUL unrar, the rars can be deleted automatically.
If there was an error because the path was too long (or the hard disk was full, happened to me too), every user can look, what happened and unrar the files with WinRar, Total Commander or other tools which can unrar successful and delete the rar and par files manually for that download.

That is a solution which would work in any case.
When I shorten the download path it's only a matter of time until it's happen again.

If you want, you could make it an option, so the users can choose what they prefer.

PLEASE help.

Kind Regards,
Calahan

[Quade]

The problem is there is no solution that'll work generally. Every version of Windows Explorer I've tested, simply won't process files longer than 255 characters. That's total length, filenames and paths. I haven't tried 8.1.

I can think about "fail unrar if too long". I think it's a good idea. I could probably remove the length limits if you use a UNC path too. UNC paths are how you make windows go over 255 chars.

You could probably knock 20 bytes or more out of the path by removing the $(GROUP). NZB's don't care about groups. You could make this only apply to NZB's too with an NZB Specific download path.