This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Nuutti.Kotivuori
Recipients Nuutti.Kotivuori
Date 2013-08-23.07:56:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
In-reply-to
Content
when tarfile generates a tar, it uses TarInfo objects which are packed to the binary format. This packing uses "itn" format for filling the "devmajor" and "devminor" fields of the tar file entry, with a default value of zero. The field length is 8 characters, and the formatting will format the values as octal strings, followed by a NUL byte, eg. '0000000\x00'.

However, other common tar tools do not exhibit this behavior, instead leaving the field filled with NUL bytes in case the earlier type field does not indicate a device type. Explicitly, the value generated by other tools is then '\x00\x00\x00\x00\x00\x00\x00\x00'.

This causes no interoperability issues (that I am aware of), but makes it hard to attempt to replicate the tar files generated by other tools exactly.

I am attaching a simple diff fixing this, but there are probably better ways to fix this.
History
Date User Action Args
2013-08-23 07:56:10Nuutti.Kotivuorisetrecipients: + Nuutti.Kotivuori
2013-08-23 07:56:10Nuutti.Kotivuorisetmessageid: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
2013-08-23 07:56:10Nuutti.Kotivuorilinkissue18819 messages
2013-08-23 07:56:09Nuutti.Kotivuoricreate