| msg160674 - (view) |
Author: Hans Werner May (hwm) |
Date: 2012-05-14 23:48 |
| 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 |
|
|
| msg160685 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2012-05-15 06:21 |
| 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? |
|
|
| msg160707 - (view) |
Author: Lars Gustäbel (lars.gustaebel) * |
Date: 2012-05-15 10:41 |
| This issue is related to 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. |
|
|
| msg160712 - (view) |
Author: Hans Werner May (hwm) |
Date: 2012-05-15 11:17 |
| "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. |
|
|
| msg161548 - (view) |
Author: David Ibarra (dtibarra) |
Date: 2012-05-25 03:33 |
| 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 |
|
|
| msg178962 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2013-01-03 16:33 |
| 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. |
|
|
| msg178971 - (view) |
Author: Марк Коренберг (socketpair) * |
Date: 2013-01-03 18:13 |
| And yes, bug does not appear in python3.2 |
|
|
| msg391952 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2021-04-26 17:19 |
| Python 2 only issue. |
|
|