Inconsistency in long path support by (integrated) packers

[Dalai]

Hi there,

Not sure if this is a real bug or more a suggestion. Feel free to move the topic if it's not appropriate here.

If one read my previous posts in the English (plugin) section, it may seem that I'm currently investigating everything that's around TC in concerning the support of long paths . I've rather discovered this issue by accident after downloading some driver files from Microsoft Windows Update Catalog that have really long names (130 at most) and sorted them into my directory structure.

Long story short: Not all of the (un)packers integrated into TC support long path names (longer than 259). RAR and ZIP are fine, but 7Z and CAB are not. The last one was the trigger to find this problem since MS almost always uses CAB. All you get when trying to open a CAB or 7Z file in a long path is

---------------------------
Total Commander
---------------------------
Error in packed file C:\path\with\long\file\name\goes\here.cab!
---------------------------
OK
---------------------------

It would be nice if long path names were supported by all integrated packers.

Regards
Dalai

[MVV]

I'm pretty sure that TC uses system CAB unpacker so it isn't so easy to fix...
Regarding 7-Zip - does 7-Zip itself support long paths?

[milo1012]

Additionally to the problem with internal 7z and cab:

Packer plug-ins are not even called for unpacking, when the base location for output files is > MAX_PATH.
You get an

Access denied!
*Path*

message in such case.
But only for unpacking to a > MAX_PATH location from a <= MAX_PATH archive.
For packing to and opening an archive with such a long path, TC just passes the current paths, and it's the plug-in's responsibility to support > MAX_PATH.

I'm not sure if it makes sense to forbid such long paths for unpacking on one hand, but more or less allowing them for packing on the other.

I'm pretty sure that TC uses system CAB unpacker so it isn't so easy to fix...

TC uses CABRK.DLL for cab unpacking (see the descript.ion file), or cabinet.dll (if available):

14.01.05 Fixed: Use cabinet.dll coming with Windows (if available) instead of cabrk.dll (made from cabinet sdk)

Additionally Windows had extract.exe in the past, or extrac32.exe on newer OSes, for cab unpacking, but no dedicated API functions.
I'm not sure about the cabinet sdk though, i.e. if it's even possible to fix it by recompiling.

[MVV]

I'm not sure if it makes sense to forbid such long paths for unpacking on one hand, but more or less allowing them for packing on the other.

Well, since most plugins don't support long paths and WCX API doesn't provide a corresponding capability flag, TC can't know about long path support.
But I agree that it may be bad to allow some functions and deny other ones. Buffer overflow may occur in a plugin if it doesn't expect long paths.

TC uses CABRK.DLL for cab unpacking (see the descript.ion file), or cabinet.dll (if available):

Even Windows 2000 had cabinet.dll so TC won't use old CABRK.DLL on modern systems. BTW, CABRK.DLL doesn't even support Unicode.

[milo1012]

Even Windows 2000 had cabinet.dll so TC won't use old CABRK.DLL on modern systems.

I wouldn't count on it. As far as I understand it, cabinet.dll is not guaranteed to be available.
Since Christian still ships that DLL anyway, it wouldn't be that hard to update it and implement Unicode support.
(it's always better to use your own functions, simply because of direct control)

Well, since most plugins don't support long paths and WCX API doesn't provide a corresponding capability flag, TC can't know about long path support.

But it knows about Unicode support, and this is enough.
If a packer plug-in exports ProcessFileW and ReadHeaderExW, you have Unicode support guaranteed, and even large enough buffers (1024 Wchars).
(TC will only call Unicode functions then)
So if now an input/output path isn't found, because the plug-in doesn't handle > MAX_PATH, it should return an error anyway.
TC doesn't prefix \\?\ itself, so using that raw long path will return errors, no matter if using it for calling API functions directly or through some runtime lib.

In short: There's no real reason to prevent it in the first place, if a plug-in is Unicode-capable.

Buffer overflow may occur in a plugin if it doesn't expect long paths.

Sorry, but if you still make any assumptions, like using some arbitrary sized buffer on stack, you have pretty much disqualified yourself as a programmer.
tHeaderDataEx(W) has a fixed buffer of 1024 Wchars. This is all you need for working with such paths.
We have enough functions in any programming language by now, to prevent buffer problems.

[Dalai]

Regarding 7-Zip - does 7-Zip itself support long paths?

Seems like it. I just opened an 7z archive in a long path without a hitch (didn't try to unpack it though) in 7z 9.38.

I'm pretty sure that TC uses system CAB unpacker so it isn't so easy to fix...

Hm, I guess you're right.

Regards
Dalai

[ghisler(Author)]

Yes, CABRK.DLL was used on Windows9x/ME. The problem is indeed that these DLLs do not support long paths because the normal Windows functions don't work with them.