You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/gustaebel'closed_at=<Date2007-12-01.21:15:56.832>created_at=<Date2007-11-30.23:00:06.371>labels= ['extension-modules', 'type-bug']
title='tarfile.open(fileobj=f) and bad metadata of the first file within the archive'updated_at=<Date2007-12-02.01:39:45.729>user='https://bugs.python.org/GeorgeNotaras'
Now, I seek to the start of the 2nd archived file's metadata:
f.seek(756)
And I try to open the tar archive using tarfile.open() passing the
previous fileobject to it.
importtarfilef_tar=tarfile.open(fileobj=f)
Traceback (mostrecentcalllast):
File"<stdin>", line1, in<module>File"tarfile.py", line1143, inopenraiseReadError("file could not be opened successfully")
tarfile.ReadError: filecouldnotbeopenedsuccessfully
Wouldn't the expected behaviour be to successfully open the tar archive
at offset 756?
It seems that tarfile.open(fileobj=f) seeks to position 0 of the
fileobject f, fails to read the 1st archived file's metadata and throws
an exception.
I fixed this in the trunk (r59260) and release25-maint branch (r59261).
Thanks for the report. If you cannot wait for the next release, I
recommend you use mode "r|" as a workaround.
BTW, 756 is absolutely no realistic example value for the position of
the second member. A header block must start on a 512-byte boundary.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: