Currently the zipfile library extracts all files as simple files, even though it contains the information of the file attributes. This patch uses them to detect if the original file was a symlink and creates it when there is a support for symlink creation.

os.symlink needs the target_is_directory argument on Windows. Maybe extract() can search for the link target in namelist() to determine if it's a directory (i.e. ends in "/"). Note that the flag gets set automatically if the target exists, so this is only a problem when a link is extracted before the target.

Also, I think it should fall back on creating a regular file if os.symlink raises OSError. On Windows this occurs if the user doesn't have SeCreateSymbolicLinkPrivilege. os.symlink raises a plain OSError in this case; no errno/winerror is set. (I don't know why it doesn't simply call CreateSymbolicLink and raise an exception for the last error, which would be ERROR_PRIVILEGE_NOT_HELD.)

Hello Eryk,

thank you for the prompt response. I have only checked that using python2.6 on `wine` and there was no `os.symlink` support there. I'm not sure how to reasonably handle the `dir` flag for Windows as theoretically the symlink can point out of the zip file.

Do you know what happens when the symlink `dir` flag is set inappropriately? I guess it silently continues, but the link wont work, right?

Well I added the `except OSError` part, please let me know, whether this version is acceptable. The situation could only be better as without this patch both OSs are stuck with text files instead of symlinks, this way at least on Linux it should work properly.

Do note that extracting a zipfile with symlinks might lead to unexpected results, for example if the path pointed to is outside of the extract dir.

Maybe the behaviour introduced in this patch should not be the default, but instead `extract` and `extractall` could take a new flag `preserve_symlinks` which would default to False? (to keep the same default as today)