When creating tar archives using the tarfile module, requested arc names are not respected. It is currently impossible to create a tar which when listing contents would give: tartvftest.tar././control./prerm./postinstTheactualresultwillbetar tvf test.tar ./ ./control ./prerm ./postinst The actual result will be tartvftest.tar././control./prerm./postinstTheactualresultwillbetar tvf test.tar ./ control prerm postinst This is caused by TarInfo's tobuf method calling normpath() on all file names, even when the user has explicitly specified a certain name.
I'm creating a debian package (.deb) for a system which uses busybox's dpkg. A deb is an ar-archive (not tar, unix ar) archive, which in turn contains two tar archives. dpkg will first extract a tar archive called control.tar.gz (or bz2) from the package, and from that tar it will extract a file stored with the path "./control". The problem is that with the current implementation of tarfile it's impossible to create a tar archive which would contain a file stored with the path "./control". This means it's impossible to use tarfile to create deb packages which would work with busybox' dpkg. I'm not 100% sure if that precise path is requirement of the deb file format, or if it is because of how busybox' dpkg is implemented. However I have not seen a packaging guide or a deb package which wouldn't have the control file stored as ./control in the tar archive.
Apparently, the .deb file format is not explicit about that, but it seems to be common practice to have all files prefixed with './'. normpath is used all over tarfile, crucial are the occurrences in TarFile.add() and TarInfo.get_info(). As you're using a unix-like system the easiest workaround is to replace the module level tarfile.normpath function with a no-op. The original assumption for using normpath on all pathnames was to keep the names in an archive clean and in their canonical form. Most occurrences of normpath date back to the 2003 original version (cp. r30613) and have never been touched. But, I found nothing in POSIX about normalizing pathnames. GNU tar and star both strip different leading path components like "./" and "../" from pathnames, but they both don't remove "./" components from inside a pathname, for example. This means that the usage of normpath seems more or less unnecessary in tarfile. I will create a patch that addresses these issues. Thanks for your report.
I have done some research in order to find a suitable behaviour for tarfile. I wrote a script to test to what extent all the different tar implementations transform input pathnames. The results can be found at http://www.gustaebel.de/lars/tarfile/wwgtd.html. My conclusion is the following: tarfile now does no pathname transformation whatsoever except for converting absolute to relative paths (to stay backwards compatible). This way tarfile is closer to POSIX, applies less magic and gives more responsibility to the user. Fixed in r74571 (trunk) and r74573 (py3k). Thanks for your report.
