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) * | 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) * | 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:01 | ethan.furman | set | status: open -> closed resolution: fixed stage: test needed -> resolved |
| 2020-02-12 19:56:09 | ethan.furman | set | messages: + msg361911 |
| 2020-02-02 03:51:40 | wchargin | set | messages: + msg361202 |
| 2020-01-22 02:15:30 | ethan.furman | set | assignee: ethan.furman messages: + msg360441 stage: patch review -> test needed |
| 2020-01-20 23:05:00 | ned.deily | set | nosy:
+ 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:25 | wchargin | set | versions: + Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 |
| 2020-01-20 18:10:17 | wchargin | set | nosy:
+ wchargin messages: + msg360327 |
| 2020-01-20 18:08:04 | wchargin | set | stage: patch review pull_requests: + pull_request17472 |
| 2013-08-25 10:58:29 | berker.peksag | set | nosy:
+ lars.gustaebel versions: - Python 2.6, Python 3.1, Python 3.2, Python 3.5 |
| 2013-08-23 07:56:10 | Nuutti.Kotivuori | create | |