 Search Results - Recent posts as of less than a minute ago |
11 Pages 1 2 3 4 5 6 7 8 9 10 11 »Showing 1 - 30 (301 results found)
|
|
|
Okay, I compressed the four *.TXT files in the Info-Zip 3.0 distribution package:
- software: A) PKZIP (2.04g, for DOS), B) Info-Zip (3.0) for DOS, C) Info-Zip (3.0) for Windows;
- compression: A) maximum, B) stored;
- for PKZIP only: A) no authentic verification (AV), B) all files stamped with AV, C) only the middle two files stamped with AV (you'll get a "archive tampered with" error when checking this with PKUNZIP).
They are attached, packaged together, to this post. If you need more samples, feel free to ask but be more specific about what files to compress how.  |
|
|
The flags look about right. Thanks for posting them.
> I created a zip file with 2 dummy files, one with greek
letters and another one with russian letters. Using unzip 6.0.0 I get ?
for both files. With unzip 6.1.0 the filenames appear just fine. The
result is the same using either zip 3.0 or zip 3.1c. So for files
created with a new zipper there should be no problems when unzipping
them using unzip 6.1.0.
Sounds like progress. Once Unicode is fully implemented for Windows in UnZip, we should be close to done.
> By the way, unzip -Zv doesn't show if the
Unicode bit is set or something that has to do with unicode, zip -su
however works just fine.
You'd have to know what to look for looking at the UnZip -Zv output. The Unicode bit is in the flag word (bit 11?) and there are two Unicode extra fields. Generally you'd only see either the bit set or the extra field or extra fields present. I see, though, that the actual flag word is not shown by unzip -Zv, just settings of some of the bits. So when native UTF-8 is used, unzip -Zv does indeed not show any indications. We need to update the unzip -Zv output.
On the other hand, zip -su was designed specifically to verify and debug Unicode.
> I have attached the zip file I created.
Thanks. |
|
|
flags file:
CC="gcc" CF="-I. -DUNIX -O3 -DASM_CRC -DLARGE_FILE_SUPPORT -DUNICODE_SUPPORT -DUNICODE_WCHAR -DUNICODE_SUPPORT -DUTF8_MAYBE_NATIVE -DNO_LCHMOD -DHAVE_DIRENT_H -DHAVE_TERMIOS_H -D_MBCS -DUNAME_M='\"i686\"' -DUNAME_O='\"GNU/Linux\"' -DUNAME_P='\"Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz\"' -DUNAME_R='\"2.6.35-gentoo-r5\"' -DUNAME_S='\"Linux\"' -DUNAME_V='\"#1 SMP PREEMPT Fri Sep 3 21:42:03 EEST 2010\"'" CRCA_O="crc_gcc.o" AS="gcc -c" LFLAGS1="" LF2="-s" CC_BZ="gcc" CFLAGS_BZ=" -O3" IZ_BZIP2="bzip2" LIBBZ2="" IZ_ZLIB=""
I created a zip file with 2 dummy files, one with greek letters and another one with russian letters. Using unzip 6.0.0 I get ? for both files. With unzip 6.1.0 the filenames appear just fine. The result is the same using either zip 3.0 or zip 3.1c. So for files created with a new zipper there should be no problems when unzipping them using unzip 6.1.0. By the way, unzip -Zv doesn't show if the Unicode bit is set or something that has to do with unicode, zip -su however works just fine. I have attached the zip file I created. |
|
|
>> The corruption error sounds typical of an archive with bad characters being looked at using an old unzip.
> The corruption error appears with the 6.1.0a version of unzip. With 6.0.0 the listing appears but with ? instead of the greek letters.
Interesting. I don't get that error with UnZip 6.1a running on Windows XP. Can you send the flags file created by the build process? That should show any special requirements of that compiler. With any luck I should be able to do some Linux testing maybe later tonight.
>> How did you create the above?
> I didn't create it. It is a zip file from the ministry of education here in greece.
They're probably using an old zipper without Unicode support.
>> You need to test Unicode with an archive that has Unicode in it.
> How can I tell if a zip file has unicode in it?
I think unzip -Zv should note either the Unicode bit being set or the existence of the Unicode extra field. If you have Zip 3.0 or later, zip -su should show the Unicode names in the archive if there are any.
> Should I try to create a zip file with zip v3.0 to archive a list of files with greek filenames and try to unzip it with the beta version of unzip?
That should work. If you have a Greek locale, you could extract the files in that archive there. Otherwise just create or grab some files that have Unicode-relevant file names. Would be good to include at least two locales, but just one should work. I'd prefer you try Zip 3.1c to create the archive as that has some minor Unicode updates. |
|
|
> The corruption error sounds typical of an archive with bad characters being looked at using an old unzip.
The corruption error appears with the 6.1.0a version of unzip. With 6.0.0 the listing appears but with ? instead of the greek letters.
> How did you create the above?
I didn't create it. It is a zip file from the ministry of education here in greece.
> You need to test Unicode with an archive that has Unicode in it.
How can I tell if a zip file has unicode in it? Should I try to create a zip file with zip v3.0 to archive a list of files with greek filenames and try to unzip it with the beta version of unzip? |
|
|
Before anyone comments about it, Unicode is still broke on Windows. I'd expect most non-ANSI characters to appear as ? there.
It does look like the ? are now one-for-one matching characters in the file names. If this is true, then that seems an improvement over the previous version where bytes in the multi-byte characters were getting their own ?. Please confirm at least this is fixed.
The corruption error sounds typical of an archive with bad characters being looked at using an old unzip.
It looks like this archive does not have Unicode extra fields or set the Unicode bit for each entry. If an old utility was used to create this archive and no Unicode was stored, then only an unzip running under the Greek locale might be able to see the Greek. How did you create the above? You need to test Unicode with an archive that has Unicode in it. |
|
|
> I tested the beta version of unzip [...]
Which "the beta version"? Built how? On what? "unzip -v" report?
Beta version of unzip (6.1.0a), built manually (make generic_gcc) on Gentoo Linux.
UnZip 6.10a BETA of 23 Aug 10, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.4.4 for Unix (GNU/Linux i686) on Sep 4 2010.
UnZip special compilation options:
ASM_CRC
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
SYMLINKS (symbolic links supported, if RTL and file system permit)
TIMESTAMP
UNIXBACKUP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)
MBCS-support (multibyte character support, MB_CUR_MAX = 6)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
VMS_TEXT_CONV
[decryption, version 2.11 of 05 Jan 2007]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none] |
|
|
> I tested the beta version of unzip [...]
Which "the beta version"? Built how? On what? "unzip -v" report? |
|
|
I tested the beta version of unzip with this file:
http://www.minedu.gov.gr/publications/docs/dt_100830.zip
The result of unzip -l dt_100830.zip is the following:
Length Date Time Name
--------- ---------- ----- ----
68608 08-30-2010 16:34
error: zipfile probably corrupt (segmentation violation)
Using the 6.00 version I get:
Length Date Time Name
--------- ---------- ----- ----
68608 08-30-2010 16:34 ??_??????????.doc
268288 08-30-2010 16:34 ??????? ?????????? ??? 2010 - 2011.doc
289280 08-30-2010 16:34 ??????? ?????????? ??? + ?? 2010 - 2011.doc
--------- -------
626176 3 files
All filenames should be in greek characters instead of question marks. |
|
|
| This may be fixed in the UnZip 6.1a beta. Would appreciate someone testing that using various character sets including UTF-8 names with multi-byte characters. |
|
|
> Again, if you need sample archives, tell me.
Yep. They could be useful to test any fixes. Examples with and without compression as well as any other significant variations may be needed to make sure the fixes work for them. |
|
|
in process.c:
if ((G.ecrec.number_this_disk != 0xFFFF) &&
(G.ecrec.number_this_disk != ecloc64_total_disks-1)) {
/* Note: For some unknown reason, the developers at PKWARE decided to
store the "zip64 total disks" value as a counter starting from 1,
whereas all other "split/span volume" related fields use 0-based
volume numbers. Sigh... */
Also checked archive too and found that zip64 total disks value was 0. After change in code (dropping -1), unzip listed archive content correctly. Maybe note in comment is not true anymore?
I believe this comment refers to how it's defined in the Zip Standard (AppNote) and I believe it's true. Now how the code handles it is another question and that should be checked. |
|
|
| Here is a compiled dll for the Zip 3.1c zip32z64.dll. The dll interface was changed between Zip 3.1b and Zip 3.1c, so this only works with the Zip 3.1c VB example and code that use that interface. |
|
|
> None of the String parameters (ZPOPT.Date, .szRootDir, .szTempDir) should be
given any value. Otherwise you will get unpredictable results. None of
the flags work either. As an example, fLevel has no effect. Setting
fTemp=1 will put the Volume Label in the .zip file, contrary to
documentation. Setting fVolume=1 does nothing. Setting fComment=1 does
nothing. The callback function ZDLLComm will not fire.
Most of these issues are documented in the comments in the zip32.dll VB example code.
> According to the documentation, call to ZpGetOptions should set ZPOPT.fEncryption=True if encryption is available. zip32.dll v2.32 sets this to False. On the other hand, it sets ZPOPT.fComment=1. Which makes no sense.
Work has been done on the recent betas to clean up the interface, though that makes the interface not backward compatible.
> The sample "VBz64" provided with zip30.zip fails to run at all. The error is #48: File not
found: zip32z64.dll. But, zip32z64.dll does exist in the application
directory as well as System32. The file was retrieved from gnuwin32
zip-3.0-bin.zip.
Works for me. The VB examples have been somewhat thoroughly tested. I would guess that something is different in your configuration than the setup I used for testing. In particular, it seems something on your system is not making zip32z64.dll visible to the application. Could be duplicate zip32z64.dll in the command path or some name conflict.
> It would seem zip32z64.dll requires bzip2.dll to run.
No, it shouldn't. There is no current build configuration for zip32z64.dll that accesses bzip2 as a dll. Well, there may be an old build script that supports that, but all recent testing is with bzip2 integrated directly. I guess we need to check the state of the bzip2 dll build options in the scripts.
> The whole process of using Info-Zip from VB6 is truly cumbersome. Is there a truly working example available?
System: VB6 SP6, WinXP SP3.
I suggest trying the Zip 3.1c example. Would appreciate feedback on that as it's a work in progress. The hope is that by release of Zip 3.1 it should be a streamlined interface. |
|
|
> [...] @exclude_list.txt
I'm confused (which happens fairly frequently, and I don't use this
stuff much on UNIX(-like) systems). What are you expecting
"@exclude_list.txt" to do? (And why?)
> I tried adding the following to the exclude file, but it was ignored.
> [...]
What, exactly, did you add to what? The command? The output from
the command? I don't see how your "exclude file" is supposed to work.
As usual, showing actual commands with their actual output can be
more helpful than vague descriptions and interpretations. (For example,
a transcript showing a "cat my_file" command, with its output, can be
more helpful than saying what you think is in some file.)
> [...] It's also possible that the command line with the `find` results
> could get very long. I don't know if that is an issue or not.
Modern shells tend to be pretty tolerant, but it could be a problem
if the command line is too long. That's why the "-@" option exists ("-@
read names from stdin"). I'd probably try something like:
find [... desired file selection ...] | zip archive.zip -@
where the "find" command handles all the file selection (and recursion),
and Zip takes its (to-do) file list from stdin (the piped output from
"find").
"-x <pattern> [...]" could still be used, but I suspect that "find"
could do any exclusions at least as well, while it's doing everything
else. |
|
|
Zip version on unix/solaris:
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008).
I need to archive a directory tree and would like to exclude files above a certain size, let's say 50MB for now. What is the best way to do this?
This is what I've tried so far seems to work:
zip -r archive_1.zip . -x `find . -size +50000ck ! -name \*.lst ! -name \*.log` @exclude_list.txt
Note that the `find` command will generate a list of files that are 50MB+ but excludes all files *.lst and *.log . I also have an exclude file that contains the following:
archive_*.zip
archive_*.log
projdata/fact/*
I tried adding the following to the exclude file, but it was ignored. It doesn't work either if enclosed in double quotes.
`find . -size +50000ck ! -name \*.lst ! -name \*.log`
My preference would be to add it to the exclude file since the criteria could get rather complicated. It's also possible that the command line with the `find` results could get very long. I don't know if that is an issue or not.
I appreciate the feedback and help,
-- Seth
|
|
|
Hey Guys,
This might be a bit old but this works, loop through the zip files and unzip them in a way
that would allow unzip to do some breakdancing.
I'm a bit new to this, appreciate the insight into dancing with seek(), tell() though, I lol'd
--------------------------
#!/bin/bash
#Author: Charl Mert @ JNZ Team
SCRIPT_ROOT="/mnt/scripts/import_joomla_templates"
#Unzipping all files that could be zipped by checking the curr dir recursively.
for ZIPFILE in `find . -name "*.zip"`
do
ZIPPATH=`echo $ZIPFILE | sed s/\.zip//g`
if [ ! -x $ZIPPATH ]; then
mkdir "$ZIPPATH"
fi
unzip $ZIPFILE -d $ZIPPATH
done; |
|
|
| Marco, can you post your source code to fix those errors? I've got a small zip file I need to heal. Thanks! |
|
|
Around here:
dyi # mkdir test_uct
dyi # cd test_uct
dyi # unzip6 ../uct.zip
Archive: ../uct.zip
inflating: uct1
inflating: uct1.c
dyi # unzip6 ../uct.zip
Archive: ../uct.zip
replace uct1? [y]es, [n]o, [A]ll, [N]one, [r]ename: n
replace uct1.c? [y]es, [n]o, [A]ll, [N]one, [r]ename: n
dyi # ls -l
total 160
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c
dyi # unzip6 -B ../uct.zip
Archive: ../uct.zip
inflating: uct1
inflating: uct1.c
dyi # ls -l
total 320
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~
dyi # unzip6 -B ../uct.zip
Archive: ../uct.zip
inflating: uct1
inflating: uct1.c
dyi # ls -l
total 480
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~1
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~1
dyi # unzip6 -B ../uct.zip
Archive: ../uct.zip
inflating: uct1
inflating: uct1.c
dyi # ls -l
total 640
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~1
-rw-r--r-- 1 root sys 1108 Aug 6 10:35 uct1.c~2
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~1
-rwxr-xr-x 1 root sys 70176 Aug 6 10:35 uct1~2
And so on.
dyi # unzip6 -v
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.3.3 for Unix (HP-UX) on Apr 28 2009.
UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
SYMLINKS (symbolic links supported, if RTL and file system permit)
TIMESTAMP
UNIXBACKUP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
UNICODE_SUPPORT [char coding: other] (handle UTF-8 paths)
MBCS-support (multibyte character support, MB_CUR_MAX = 1)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)
VMS_TEXT_CONV
[decryption, version 2.11 of 05 Jan 2007]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]
Note "UNIXBACKUP" in the feature list.
dyi # unzip6 -hh
Extended Help for UnZip
[...]
unzip modifiers:
[...]
-B [UNIXBACKUP compile option enabled] Save a backup copy of each
overwritten file in foo~ or foo~99999 format.
[...]
dyi # uname -a
HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license
So, as shown, an UnZip 6.0, which was built with the "UNIXBACKUP"
feature enabled, on an HP-UX system, when "-B" was specified on the
command line, seems to work as documented. If you can provide a
comparable description of it not working, then someone will probably be
willing to investigate. Note that a "comparable description" would
include an "unzip -v" report (plus any other system description which is
not obvious from that), and a transcript showing the actual commands
used, with their actual output. _Then_, after some actual facts have
been revealed, you can begin to comment on what it all means to you.
> "[...] feature UNIXBACKUP [...] is now enabled by default."
This may have been confusing. In previous UnZip versions, the user
needed to enable the UNIXBACKUP feature (with its "-B" command-line
option) explicitly at build time. Now, the UNIXBACKUP feature is
enabled by default. However, at run time, the user needs to specify the
"-B" command-line option to activate the feature. The default behavior
-- ask the user for permission to overwrite -- has not changed.
As usual, everything's complicated. |
|
|
A useful problem report would include some basic information, like,
say, an "unzip -v" report, so we could do more than guess at where
you're running what, and which features are enabled in it. Then, an
actual transcript showing exactly what you're doing, and what happens
when you do it, would also be nice. |
|
|
The readme file claims that "On OS/2, Win32, and Unix, the (previously optional) feature UNIXBACKUP to allow saving backup copies of overwritten files on extraction is now enabled by default."
Unless I'm mistaken I take that to mean it adds the ascii tilde ~ to the file name.
If so I must be doing something wrong because when I extract, unzip keeps prompting me or overwriting.
I want to extract several zips at once, which often contain duplicate file names, i.e. file0001.txt, or all 24 files in a single zip will be named "file.txt" (how helpful!). For the record, this isn't my doing. |
|
|
| So, did zip -FFv on original archive and archive was recovered without errors. |
|
|
Hi,
Got similar problem:
Archive: 5gbfile.zip
warning [5gbfile.zip]: 1074560753 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [5gbfile.zip]: start of central directory not found;
zipfile corrupt.
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
My archive was created by Zmanda client on Win32 (pkzip.dll). I switched DEBUG on in unzip, recompiled it and ran again. Found, that failure was caused by following check in process.c:
if ((G.ecrec.number_this_disk != 0xFFFF) &&
(G.ecrec.number_this_disk != ecloc64_total_disks-1)) {
/* Note: For some unknown reason, the developers at PKWARE decided to
store the "zip64 total disks" value as a counter starting from 1,
whereas all other "split/span volume" related fields use 0-based
volume numbers. Sigh... */
Also checked archive too and found that zip64 total disks value was 0. After change in code (dropping -1), unzip listed archive content correctly. Maybe note in comment is not true anymore?
pkzip.dll is dated to 2008
I will post zip -FFv details soon...
A |
|
|
| grammy were you able to resolve this issues I have the exact same issue, I was think after the ShellExecute to read from stdout and parse the output |
|
|
> > [...] it contains authentic verification [...]
>
> I don't know what that is. Is it described anywhere in the APPNOTE?
> "Authenticity Verification"?
Authentic verification adds extra data which, when present, PKUNZIP checks and 1) displays the name and serial number of the registered PKZIP user who created the archive and 2) warns if one or more files have been tampered with. Yes, this is legacy stuff.
> > I'm a hacker [...]
>
> You're frightening me. (But that's easy to do.)
I somehow feel that there was a bit of irony in there which I don't think I deserved. (I'm also sceptic about bug reports related to my own software, that I've been coding for more than a decade, but one needs to be more careful than rejecting them by principle.) If I seemed to be boasting then sorry about it: what I meant is that I'm used to disecting stuff - even in its original binary form, if needed. However...
> > [...] so if you can tell me where to look, [...]
>
> If I need to tell you, ...
... being a hacker doesn't mean that I code well in whatever language Info-Zip is written in or that I have a compiler with which I can turn it into binary form for testing some source modifications. Actually, I do both but that's not the point: as you know Info-Zip an order of magnitudes better than I, I assumed it would be much easier for you to guide me about where to look at and then I'll continue from there on my own. Anyway, I approached the problem from a different side, that of actual results... I think the latest version of APPNOTE is at http://www.pkware.com/documents/casestudies/APPNOTE.TXT - at least, this is what I downloaded right now and I used for identifying data fields and values.
I grabbed a few smaller files and archived them with:
- PKZIP for DOS;
- PKZIP for DOS, enabling authentic verification, but only for some of the files;
- Info-Zip for DOS;
- Info-Zip for Windows;
storing all files without compression so that the small differences in the compression ratio, resulting in slightly different "compressed size" values, wouldn't disturb the comparisons (i.e. binary diff).
The results for PKZIP for DOS, file headers in the central directory structure:
- sets "version made by" to 0x0014: DOS platform [*], ZIP 2.0;
- sets "internal file attributes" to 0x0001: text file;
- sets "external file attributes" to 0x00000021: all the files have the "read only" and "archive" bits set (they really do so this is correct).
[*] Obviously, DOS platform includes Windows, too, as it is rather the file system that this value refers to: in FAT file systems, there are only the simple attributes and it is NTFS (platform = 10, 0x0A) that has a lot more.
Info-Zip for DOS (differences compared with PKZIP for DOS):
- sets "internal file attributes" to 0x0000: bits 1-2 are reserved by PKWARE.
Info-Zip for Windows (differences compared with PKZIP for DOS):
- sets "version made by" to 0x001E: DOS platform, ZIP 3.0.
- sets "internal file attributes" to 0x0000: bits 1-2 are reserved by PKWARE.
PKZIP for DOS, enabling authentic verification (differences compared with PKZIP for DOS). At the first file only, whether or not AV is enabled for it:
- sets "extra field length" to 32;
- adds an "extra field", with the type of 0x0007 (AV info) and length of 0x001C: this is what contains the registered name and serial number (encrypted).
If not all files have AV enabled then the same changes are applied to the _local_ file header of the first file, in which case "relative offset of local header" values are obviously also adjusted. Furthermore, only for files with AV enabled:
- sets "internal file attributes" to 0x0005: text file, bit 3 apparently refers to the presence of the extra AV checksum;
- sets "external file attributes" to 0xXXXXXX21: for DOS platform, only the lowest byte makes sense (not my idea, see APPNOTE!), the upper, non-zero, 3 bytes are apparently the extra AV checksum.
The correct solution would be to ignore the upper 3 bytes of the external file attributes for archives marked as created on the DOS platform as this is what the APPNOTE tells. However, if there are some archives - created by Info-Zip itself?! - that are marked as having been created under DOS _but_ contain the extra Unix-style file attributes then the correct solution would break compatibility with them.
So, then clean solution is ignoring the upper 3 bytes of the external file attributes when bit 3 of the internal file attributes is set, indicating the presence of a PKZIP-style authentic verification checksum squeezed into those, assumedly unused, 3 bytes. Info-Zip doesn't use bit 3 of the internal file attributes for any purposes and always sets it to zero, right?
Again, if you need sample archives, tell me. |
|
|
All I see in the APPNOTE regarding "Authenticity Verification" ("AV")
involves an extra field, nothing related to these file attribute bits. |
|
|
> [...] it contains authentic verification [...]
I don't know what that is. Is it described anywhere in the APPNOTE?
"Authenticity Verification"?
> I'm a hacker [...]
You're frightening me. (But that's easy to do.)
> [...] so if you can tell me where to look, [...]
If I need to tell you, ...
The ZipInfo ("unzip -Z") report comes from zipinfo.c. Look for
"non-MSDOS external file attributes". Note
whatever.crec.external_file_attributes. Follow that around, including,
I'd guess, unix/unix.c (where its friend, whatever.pInfo->file_attr gets
set and interpreted). All I know is what I read in the comments. |
|
|
Hi guys,
I created that archive. There's nothing wrong with it, the only unusual thing about it is that it contains authentic verification created by (the registered version of) PKZIP 2.04g for DOS. I'm a hacker so if you can tell me where to look, I can inspect things myself and make recommendations. (I know the inside of the ZIP archive format in general as the particular software in this archive supports it, with the help of... tadaaa... Info-Zip for DOS.) Also, if you'd like a few sample archives with PKZIP AV on it, send me some sample files and I'll archive them.
Joe |
11 Pages 1 2 3 4 5 6 7 8 9 10 11 »Showing 1 - 30 (301 results found)
|
|
