TC 7.04a: Error unpacking ZIP created by TC („test”.zip)

[Gyla]

OS: WinXP SP3 HUN, NTFS, Hungarian regional settings

1. Create a text file with this name: „test”.txt (including the quotation marks)
2. Pack it into a ZIP using TC
3. Now try to unpack the ZIP

It won't succeed because the „” (84,94) characters are converted into normal quotation marks "" (22,22)

[petermad]

Confirmed!

The file can not be packed with ARJ (2.8.4), and the file name is packed uncorrectly with TC plugin SQX ("test_.txt).

[roentgen]

It seems to be a .zip format problem.
WinRAR and 7-zip both can't unpack it. (they both offer to rename the extracted file to "_test_.txt") and they both pack it with incorrect name.

[Gyla]

If I pack such a file with WinRAR 3.80, then unpack it, I will get the same file that I packed. This is the logical behaviour.

[roentgen]

2Gyla
Not here when packing as .zip with WinRAR. When packing as .rar everything is fine both in TC and WinRAR.

[Gyla]

I see, I get your point.

I meant:

„test”.txt -> test.rar

In this case, when I try to view the file inside (F3), I get a disk read error.
However WinRAR can correctly open and view it.

[roentgen]

„test”.txt -> test.rar

In this case, when I try to view the file inside (F3), I get a disk read error.
However WinRAR can correctly open and view it.

Well, this is a known fact considering that TC 7.04a doesn't support unicode.
TC 7.5 will be fully unicode aware and it will have no problems with rars which contain unicode filenames.

[ghisler(Author)]

This has nothing to do with Unicode, but with the fact that ZIP files use OEM/DOS characters by default. Apparently the Windows function CharToOem converts the quotes (which are not present in the DOS charset) to standard quotes "".

Currently the only workaround is to force TC to use the Windows charset, but this will cause problems to various unpackers.

wincmd.ini
[Packer]
ZipAnsiNames=1

Description from the help:
1:Save file names with Ansi (Windows) instead of OEM (DOS) characters in zip. Note that some unpackers cannot handle archives with accents in this case.

[karlchen]

Hello, Christian.

The real problem is this:

If we use the default setting "ZipAnsiNames=0" in order to create ZIP files which remain compatible with older ZIP programmes and standards, then the Windows function CharToOem is not totally unlikely to convert filenames which hold non-OEM-characters like „test”.txt into filenames which are illegal like "test".txt and which can not be extracted from the ZIP-file.

Kind regards,
Karl

[petermad]

which can not be extracted from the ZIP-file

Well, they can be extracted - they can just not be written to the local disk under Windows.

They can be renamed inline before extracting with no problems.

[karlchen]

Hi, Peter.

Yes, you are right.

Using T.C. you can rename "test".txt to something legal like e.g. _test_.txt and extract _test_.txt to disk.
Using 7Zip v4.62 you can directly extract "test".txt to disk as _test_.txt, because 7Zip will rename the file while extracting to disk automatically.

Wish you a Happy New Year,
Karl
--
Coming soon, New Year v2009 ...

[Clo]

2karlchen

Hello !

• Even using ZipAnsiNames=1, there is an isssue with a file “test”.txt (#147-148 ANSI) :
- Pack it with WinRar 3.5 >> It's OK, the curly guillemots are kept inside the archive, the file can be unpacked.
- With TC ZIP : The file is packed, but then the curly guillemots are changed into " " keyboard ones,
the file can't be unpacked with a write error, of course…
- That isn't a specific problem of packing, there is also a bug in the Win Clipboard formats,
and¦or how the programmes use them… In example :
¤ In ResourceHacker (Delphi), edit a script of any executable, set a complete ANSI font (Tahoma, Arial…, script and R.H. GUI)
¤ Enclose a word within these guillemots “word”, copy this into the clipboard. >> Compile >> OK
¤ Paste it in the same script in another instance of RH :
The guillemots have been changed into " " from the Clipboard >> Compilation error.
¤ Paste the same content into an editor1 : it's OK
¤ In another editor2 >> Changed into " "
• That doesn't occur with all upper ANSI characters, i.e. the ellipsis #133 … is not changed in the same handlings…
- Long dashes #150-151 are changed into - minus keyboard character…


 VG
Claude
Clo
And…

HAPPY NEW YEAR TO EVERYBODY HERE !

[DrShark]

“test”.txt

Using WinRar 3.62, no problems with packing, extracting file and displaying file's name in rar archive.

There are problems using internal unzip in TC 7.5.
File packing and extracting works fine under 7.5, and it's name in archive displaying correct in 7.04a.
But in 7.5 “test”.txt showing as 'test'.txt with default settings and as УtestФ.txt if ZipAnsiNames=1.

[karlchen]

Hello, DrShark.

In order to get the correct result in most cases - I cannot promise it will be in each and every case, but in all cases which I tested - forget about the ZipAnsiNames=0|1 setting.
T.C. 7.50 can use Unicode instead. So it is much smarter using ZipUnicode=3 instead.
See Configuration - ZIP Packer:
Pack Unicode names: All as UTF-8 if at least one contains non-English characters

Have just repeated the test using the filename “test”.txt as well as the initial filename „test”.txt from Gyla's post. No hassle here, packing or unpacking, ZipUnicode=3.

Kind regards,
Karl
--
+ Windows XP Prof SP2, 32bit, GER
+ Total Commander v7.50 Public Beta 1

[DrShark]

forget about the ZipAnsiNames=0|1 setting ... T.C. 7.50 can use Unicode instead. So it is much smarter using ZipUnicode=3 instead.

ZipUnicode is for packing. How does it help to display names in archives, created in previous versions of Total Commander?