[8.0ß11] Archive files attribute in packed files (WCMZIP32)

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: Hacker, petermad, Stefan2, white

Post Reply
User avatar
mame
Junior Member
Junior Member
Posts: 54
Joined: 2011-12-03, 18:48 UTC
Location: Everywhere

[8.0ß11] Archive files attribute in packed files (WCMZIP32)

Post by *mame »

I noticed that TC zip packer function has been fixed since beta 1:
Directory no longer gets archive attribute when being packed (if it's not already have it in unpacked form)

The issue remains with files. Files which doesn't have archive bit will have one if packed using either internal ZIP or internal TAR. Likewise, if a file in ZIP doesn't have archive bit, it will when unpacked. Means this issue affects both pack and unpack function.

Archive Formats (all passed):
Tested 7-Zip plugin (0.7.6.5). RAR.EXE/WinRAR.exe (3.93, 4.01). ARJ, ARJ32 (2.85, 3.15). LHA/LHA32 (2.55/1.06). ACE (2.04). Not sure about others but I just tested these (what I have).

ZIP packers (all passed):
I also tested other ZIP packers: 7Zip 9.20, WinRAR 4.01, IZArc 4.1.6, PKZIP 2.50, 4.00, 5.00, 6.00 (command-line), Info-ZIP 3.0 (command-line). All are able to store/unpack file without archive attribute bit set properly.

Others (all failed):
tar (GNU tar) 1.12 produces same result as TC (ie. adding archive attributes to packed files). PKZIP (for DOS) 2.04g, 2.50 does (old behaviour, perhaps?)

Conclusion:
I'm not sure about TAR format specification, especially it's not DOS/Windows native. But as for ZIP, I can be very sure that almost all packers (for Windows) tested actually behaves as they should. Except WCMZIP32 :(

Seems like this behaviour is still there in current build of TC (8.0 b11). Is it intentional (say, have to rewrite the whole pack/unpack routine) or not...?

P/S: I figured that, without WCMZIP32.DLL, TC can still unpack ZIP files, only can't create one? Does this mean to fix this thing both EXE and DLL have to be fixed?

P/S #2: I'll test x64 later, if this generates interest, or somebody else can too :wink:
I hereby claim copyright to this message you are now reading,
and for that you owe me a $1 royalty fee each time you read this.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50532
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

I noticed that TC zip packer function has been fixed since beta 1:
Directory no longer gets archive attribute when being packed (if it's not already have it in unpacked form)

The issue remains with files.
Actually it's now exactly as when you copy normally: Files which are copied get the archive attribute, folders don't.
P/S: I figured that, without WCMZIP32.DLL, TC can still unpack ZIP files, only can't create one? Does this mean to fix this thing both EXE and DLL have to be fixed?
Unpacking is done internally (in Delphi). The wcmzip32.dll only does the actual packing (number crunching), not the file name and attribute handling (done within TC).
Author of Total Commander
https://www.ghisler.com
User avatar
mame
Junior Member
Junior Member
Posts: 54
Joined: 2011-12-03, 18:48 UTC
Location: Everywhere

Post by *mame »

ghisler(Author) wrote: Actually it's now exactly as when you copy normally: Files which are copied get the archive attribute, folders don't.
I do feel that. I thought my message was clear, what I meant was;
Packing a.k.a. archiving should be treated as archiving IMHO, not the same as copying, i.e. retaining if possible everything, including archive-or-not bits.

That is why I've listed the 'packers' results, for comparison...

I don't know about delphizip behaviour (not sure if thats teh one being used, though)
I hereby claim copyright to this message you are now reading,
and for that you owe me a $1 royalty fee each time you read this.
Post Reply