classification
Title: tarfile fills devmajor and devminor fields even for non-devices
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ethan.furman Nosy List: Nuutti.Kotivuori, ethan.furman, lars.gustaebel, wchargin
Priority: normal Keywords: patch

Created on 2013-08-23 07:56 by Nuutti.Kotivuori, last changed 2020-02-14 16:03 by ethan.furman. This issue is now closed.

Files
File name Uploaded Description Edit
tarfile.py.diff Nuutti.Kotivuori, 2013-08-23 07:56 patch
Pull Requests
URL Status Linked Edit
PR 18080 merged wchargin, 2020-01-20 18:08
Messages (5)
msg195949 - (view) Author: Nuutti Kotivuori (Nuutti.Kotivuori) Date: 2013-08-23 07:56
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.
msg360327 - (view) Author: William Chargin (wchargin) * Date: 2020-01-20 18:10
I've just independently run into this and sent a patch as a pull
request. Happily, once this is fixed, the output of `tarfile` is
bit-for-bit compatible with the output of GNU `tar(1)`.

PR: <https://github.com/python/cpython/pull/18080>
msg360441 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2020-01-22 02:15
Thanks for moving this issue forward, William!
msg361202 - (view) Author: William Chargin (wchargin) * Date: 2020-02-02 03:51
My pleasure. Is there anything else that you need from me to close this
out? It looks like the PR is approved and in an “awaiting merge” state,
but I don’t have access to merge it.
msg361911 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2020-02-12 19:56
New changeset 674935b8caf33e47c78f1b8e197b1b77a04992d2 by William Chargin in branch 'master':
bpo-18819: tarfile: only set device fields for device files (GH-18080)
https://github.com/python/cpython/commit/674935b8caf33e47c78f1b8e197b1b77a04992d2
History
Date User Action Args
2020-02-14 16:03:01ethan.furmansetstatus: open -> closed
resolution: fixed
stage: test needed -> resolved
2020-02-12 19:56:09ethan.furmansetmessages: + msg361911
2020-02-02 03:51:40wcharginsetmessages: + msg361202
2020-01-22 02:15:30ethan.furmansetassignee: ethan.furman
messages: + msg360441
stage: patch review -> test needed
2020-01-20 23:05:00ned.deilysetnosy: + ethan.furman

versions: - Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
2020-01-20 18:10:25wcharginsetversions: + Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
2020-01-20 18:10:17wcharginsetnosy: + wchargin
messages: + msg360327
2020-01-20 18:08:04wcharginsetstage: patch review
pull_requests: + pull_request17472
2013-08-25 10:58:29berker.peksagsetnosy: + lars.gustaebel

versions: - Python 2.6, Python 3.1, Python 3.2, Python 3.5
2013-08-23 07:56:10Nuutti.Kotivuoricreate