tarfile does not support timestamp older 1970-01-01

[hwm]

BPO	14810
Nosy	@loewis, @gustaebel, @socketpair, @iritkatriel

^{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 = <Date 2021-04-26.17:19:58.113>
created_at = <Date 2012-05-14.23:48:28.220>
labels = []
title = 'tarfile does not support timestamp older 1970-01-01'
updated_at = <Date 2021-04-26.17:19:58.112>
user = 'https://bugs.python.org/hwm'

bugs.python.org fields:

activity = <Date 2021-04-26.17:19:58.112>
actor = 'iritkatriel'
assignee = 'lars.gustaebel'
closed = True
closed_date = <Date 2021-04-26.17:19:58.113>
closer = 'iritkatriel'
components = []
creation = <Date 2012-05-14.23:48:28.220>
creator = 'hwm'
dependencies = []
files = []
hgrepos = []
issue_num = 14810
keywords = []
message_count = 8.0
messages = ['160674', '160685', '160707', '160712', '161548', '178962', '178971', '391952']
nosy_count = 6.0
nosy_names = ['loewis', 'lars.gustaebel', 'socketpair', 'hwm', 'dtibarra', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue14810'
versions = ['Python 2.7']

[hwm]

Bug in tarfile:

In extractall, when a file exists in tarball with changetime older than (I don't know, in my case it was year 1956) tarfile raises an Overflow exception:

File "/usr/lib64/python2.7/tarfile.py", line 2298, in utime
os.utime(targetpath, (tarinfo.mtime, tarinfo.mtime))
OverflowError: Python int too large to convert to C long

System: Mageia 1.0
Python version: 2.7.1

[loewis]

The tar file format does nt support timestamps before 1970. From

http://sunsite.ualberta.ca/Documentation/Gnu/tar-1.13/html_chapter/tar_8.html

"POSIX tar format can represent time stamps in the range 1970-01-01 00:00:00 through 2242-03-16 12:56:31 UTC." ...
"Portable archives should also avoid time stamps before 1970. These time stamps are a common POSIX extension but their time_t representations are negative. Many traditional tar implementations generate a two's complement representation for negative time stamps that assumes a signed 32-bit time_t; hence they generate archives that are not portable to hosts with differing time_t representations."

Out of curiosity: where did you get a file that was last modified in 1956?

[gustaebel]

This issue is related to bpo-13158 which deals with a GNU tar specific extension to the original tar format. In that issue a negative number in the uid/gid fields caused problems. In your case the problem is a negative mtime field.

Reading these particular number fields was fixed in Python 3.2. You might be able to read the archive in question with that version. You should definitely try that.

Besides that, I was unable to reproduce the error you report. I just did some tests and could not even open my test archive, because it was not recognized as a tar file. I didn't come as far as the os.utime() call.

[hwm]

"Out of curiosity: where did you get a file that was last modified in 1956?"

No idea, this was a jpeg file, probably downloaded from internet. Btw, on Linux you can manipulate the creation date with the touch command, so it is possible to create a tarball with a member which has creation date 1956, but it is not possible to extract it with the extractall method.

[dtibarra]

I too cannot reproduce this, tarfile seems to recognizes that it isn't a valid tar file (tested on OS X):

Davids-MacBook-Air:Workspace dibarra$ ls -l
total 8
-rw-r--r-- 1 dibarra staff 0 May 30 1956 testfile
Davids-MacBook-Air:Workspace dibarra$ tar -cvf testfile.tar testfile
a testfile

>>> t = tarfile.TarFile("testfile.tar")
Traceback (most recent call last):
...
tarfile.ReadError: missing or bad subsequent header

[socketpair]

Yes, bug exists in python 2.7. The same problem - negative timestamp in mtime field. It prepresented in binary value as

'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xc7\xfc'

in my case.

[socketpair]

And yes, bug does not appear in python3.2

[iritkatriel]

Python 2 only issue.