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.
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).
> * "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.
