zipfile: symlinks etc.

[ronaldoussoren]

BPO	18595
Nosy	@jcea, @ronaldoussoren, @takluyver, @serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2013-07-30.07:45:18.689>
labels = ['type-feature', 'library']
title = 'zipfile: symlinks etc.'
updated_at = <Date 2016-01-15.15:20:56.539>
user = 'https://github.com/ronaldoussoren'

bugs.python.org fields:

activity = <Date 2016-01-15.15:20:56.539>
actor = 'takluyver'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-07-30.07:45:18.689>
creator = 'ronaldoussoren'
dependencies = []
files = []
hgrepos = []
issue_num = 18595
keywords = []
message_count = 5.0
messages = ['193915', '194234', '194240', '194264', '252482']
nosy_count = 5.0
nosy_names = ['jcea', 'ronaldoussoren', 'takluyver', 'serhiy.storchaka', 'xcombelle']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18595'
versions = ['Python 3.5']

[ronaldoussoren]

The zipfile format (as described by .zip file format specification) allows for storing extra unix data, such as symlinks and device nodes in zipfile.

Storing at least symlinks would be useful, and is supported by the infozip tools as well (the command-line zip and unzip commands on Linux systems).

An implementation would use the "UNIX Extra Field (0x000d)" to store this information.

[jcea]

Ronald, could you try to write a patch?

[ronaldoussoren]

My initial plan was to add the patch soon after filing the issue, but that's before I noticed that this needs some API design to integrate nicely :-)

My current idea for the api:

• add "symlink(path, target") to write a symlink

• add "readlink(path)" to read a symlink

• "read" will raise an exception when trying to read a symlink
  (alternative: do symlink resolving, but that's too magical to my taste)

• "extract" and "extractall" extract the symlink as a symlink
  (but I'm not sure yet what to do on systems that don't support symlinks)

• with the various file types it might be better to also provide
  "islink(name)", "isdir(name)" and "isfile(name)" methods (simular to
  their os.path equivalents)

This will also require some changes to the ZipInfo class.

I'm not sure yet if adding support for device files and other unix attributes (UID/GID).

[serhiy-storchaka]

• "read" will raise an exception when trying to read a symlink
  (alternative: do symlink resolving, but that's too magical to my taste)

And perhaps when trying to read a directory entry too.

• "extract" and "extractall" extract the symlink as a symlink
  (but I'm not sure yet what to do on systems that don't support symlinks)

What the tar module do?

• with the various file types it might be better to also provide
  "islink(name)", "isdir(name)" and "isfile(name)" methods (simular to
  their os.path equivalents)

Or rather as methods of the ZipInfo object. See TarInfo.

[xcombelle]

about the readlink functionnality, I would like to point that it might lead to security issues see for example https://security.stackexchange.com/questions/73718/how-zip-symlink-works

At least, the standard read should not do it by default.

[gpshead]

closing as a duplicate of #82102