This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: zipfile: use correct system type on unixy systems
Type: Stage:
Components: Library (Lib) Versions: Python 2.5
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: loewis, pete_forman, ronaldoussoren
Priority: normal Keywords: patch

Created on 2006-01-23 14:48 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
zipfile.patch ronaldoussoren, 2006-01-23 14:48
zipfile-2.patch ronaldoussoren, 2006-01-26 10:34 updated version
Messages (8)
msg49396 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-01-23 14:48
This patch updates the contructor of zipfile.ZipInfo to initialize the 
create_system attribute to 3 instead of 0 on systems that are not 

Without this patch the unzip command won't honour the file mode that is 
stored in the zip file.
msg49397 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-01-26 10:34
Logged In: YES 

I've updated the patch based on a simular patch by Pete Forman (UID: 
pete_forman). This version contains a lookup-table of create_systems based on 
the and also supports some other non-windows systems.
msg49398 - (view) Author: Pete Forman (pete_forman) Date: 2006-01-26 16:49
Logged In: YES 

The merged patch looks good.

One extra comment that I'd made was that if is 
'java' then a further query of 
java.lang.System.getProperty("") might be in order.  
The string returned from that is 'Linux', 'Windows XP' and 
'SunOS' on the platforms I can test.  A quick search turned 
up this page:

On that basis I'd propose a rule that if the Java 
starts with 'Windows' or 'OS/2' then use 0; if it starts 
with 'Mac OS' then 7; else 3.  Perhaps someone with 'Mac OS 
X' could pronounce whether it ought to be 3 (UNIX) or 7 
(Macintosh).  Comments from Jython experts welcome as well.

The spec for the ZIP file format is at PKWARE.
msg49399 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-01-31 20:36
Logged In: YES 

I think it is more complicated than that. In version 6.2.2,
a value of 19 is assigned to OS/X. There might also be cases
when 10 (Windows NTFS) is the right answer; it appears they
look at the file system rather than the operating system.

HOWEVER, it also says that the value should be 0 if the
external file attributes are compatible with DOS and pkzip

Perhaps it is a bug in unzip that it doesn't honor the file
msg49400 - (view) Author: Pete Forman (pete_forman) Date: 2006-02-01 11:00
Logged In: YES 

I would contend that UNIX file permissions are not
compatible with MS-DOS though it is possible that PKZIP
2.04g might read them and convert them to an approximation.
I would hope that an unzipping program would ignore any file
type code that it did not know how to interpret.  The ZIP
spec explicitly says the the external file attributes are
set to zero in the case where input is from standard input.
I infer from that that an unzipper should at least be able
to extract the bytes of a file.

Rather than argue over fine points of interpretation I think
that we should take the pragmatic view that a ZIP archive is
most likely to be unzipped on the same type of file system
that it was created on.

The file system code is indeed more complicated.  Setting
one type for the archive is limiting.  It ought to be set
for each member.  And yes, it should be file system rather
than OS.

unzip does honor the file mode.  External file attributes
must be interpreted according to 'version made by'.  It does
have options such as '-X restore UID/GID info' but those
control how much metadata is unpacked, not override
incorrect fields.
msg49401 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-02-05 07:21
Logged In: YES 

I looked at the "compatible with DOS" issue again, and I
think the story is this:

The low-order byte of the external file attributes are the
DOS bits (read-only, hidden, system, directory); one can
claim compatibility if these bits have the right values. The
Unix bits are the higher 16 bits, and can have indepedent

InfoZIP (on Unix) will use the Unix bits as is-if the
creator system is UNIX, VMS, ACORN, ATARI, ATHEOS, BEOS,
QDOS or TANDEM. For FAT (0), it will use the Unix bits if
they are "consistent" with the DOS bits. In all other cases
(including NTFS and MAC), it will use the DOS bits.

"consistent" is defined wrt. the U bits: the DOS directory
bit must be the same as the u+x bit, and the u+w bit must be
the negated read-only bit.

If only the DOS bits are used, they are used to synthesize
POSIX bits: u,g,o get all the same bits, the w bits are
derived from read-only, and the x bit is derived from the
subdir bit.

As for -X (restore UID/GID): They come from the PK Unix
extra field (0x000d), the InfoZip Unix extra field (0x5855)
or the InfoZIP Unix2 extra field (0x7855). We currently
don't create any of these, so this option in unzip won't
have any effect.
msg49402 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-02-05 14:35
Logged In: YES 


Thank you for investigating this. It seems to me that my original patch should 
be save then, it sets the creator_system to unix on unix-y systems only. 

The current version of zipfile sets the higher 16 bits external_attr to the file 
mode as returned os.stat and doesn't set the lower bits at all (the comment 
mentions 'unix attributes').

As you already noticed zipfile doesn't set any other attributes, such as user 
and group, and IMHO that wouldn't be very useful for most usecases anyway.
msg49403 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-02-05 17:14
Logged In: YES 

I agree, and have committed the original patch as r42250.
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42827
2006-01-23 14:48:00ronaldoussorencreate