Zip files cannot be read with Windows unarchiver

[Emmanuel Blot]

The default Windows zip unarchiver (Win XP) fails to manage ZIP archives produced by Trac from the Changeset view.

When such an archive is open, the archive appears to be empty, whereas it actually contains the zipped files.

When a third party tools such as IZarc is used to browse the archive content, the files appear in a unamed directory - the top level directory name seems to be empty.

It seems the issue is due to the way filenames are stored in the ZIP archive: the leading path separator seems to be the root cause of both these issues.

From a more general perspective, I don't think the leading / separator should be kept in a ZIP archive: it could be dangerous. tar unarchiver warns about such a situation (and discards the leading path separator when the TAR archive is inflated), so does the unzip tool:

blote@host:~/tmp/zip$ unzip ~/changeset_r2148.zip
Archive:  /home/blote/changeset_r2148.zip
warning:  stripped absolute path spec from /branches/t991b/.../activity.cpp
...

Attaching a patch that removes the leading path separator.

Let me know if you want me to commit it

[Emmanuel Blot]

Remove leading / from archived file names

[Christian Boos]

Are you sure it's not the utf-8 encoding which is causing the issue with the default unarchiver?

Otherwise, stripping the leading "/" is a good idea (and you could actually use new_node.path.strip('/').encode('utf-8') for that).

[Emmanuel Blot]

Replying to cboos:

Are you sure it's not the utf-8 encoding which is causing the issue with the default unarchiver?

I have not checked it but getting rid of the leading "/" fixed up the trouble and as the full pathname contains only ASCII characters the UTF-8 conversion should not alter the resulting pathname.

Otherwise, stripping the leading "/" is a good idea (and you could actually use new_node.path.strip('/').encode('utf-8') for that).

Yes, you're right.

[Emmanuel Blot]

Fix in [4937].