[issue12841] Incorrect tarfile.py extraction

Lars Gustäbel l...@gustaebel.de added the comment: Yes, I can do that as soon as I've managed to wrap my head around using Mercurial and the new way of developing Python. I have been away from Python programming for quite some time and haven't adapted my workflow yet

[issue12841] Incorrect tarfile.py extraction

Lars Gustäbel l...@gustaebel.de added the comment: The patch is fine. Thank you very much for it, Sebastien. I think we have to go without a unit test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12841

[issue11899] TarFile.gettarinfo modifies self.inodes

Lars Gustäbel l...@gustaebel.de added the comment: Good point. Do you happen to have a working implementation already? -- assignee: - lars.gustaebel priority: normal - low versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org

[issue11879] TarFile.chown: should use TarInfo.uid if user lookup fails

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11879

[issue11787] File handle leak in TarFile lib

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11787 ___ ___ Python-bugs

[issue7101] tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file

Lars Gustäbel l...@gustaebel.de added the comment: I kept this issue open, because I have not yet come to a decision. I don't think the current behaviour is a bug, but these kinds of errors could be handled more intelligently. For example, errors during extraction can be hidden depending

[issue11449] tarfile tries to file_.tell() even when creating a new archive

Lars Gustäbel l...@gustaebel.de added the comment: If I understand correctly, the solution to your problem would be to use the stream mode w| instead of w. Could you please try that? -- assignee: - lars.gustaebel ___ Python tracker rep

[issue11457] Expose nanosecond precision from system calls

Changes by Lars Gustäbel l...@gustaebel.de: -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list

[issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows

Lars Gustäbel l...@gustaebel.de added the comment: Thanks for your great report. This is fixed now in r88528 (py3k) and r88529 (release32-maint). -- keywords: +3.2regression resolution: - accepted stage: - committed/rejected status: open - closed versions: +Python 3.3

[issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows

Lars Gustäbel l...@gustaebel.de added the comment: _FileInFile.read() does lots of unnecessary seeking and reads the same block again and again. The attached patch fixes that. Please try if it works for you. -- assignee: - lars.gustaebel keywords: +patch Added file: http

[issue10760] tarfile doesn't handle sysfs well

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel components: +Library (Lib) -None nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10760

[issue10761] tarfile.extractall fails to overwrite symlinks

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10761

[issue10261] tarfile iterator without members caching

Lars Gustäbel l...@gustaebel.de added the comment: There is no trivial or backwards-compatible solution to this problem. The way it is now, there is no alternative to storing all TarInfo objects: there is no central table of contents in an archive we could use, so we must create our own

[issue10292] tarinfo should use relative symlinks

Lars Gustäbel l...@gustaebel.de added the comment: Okay, this bug has been fixed in the 2.7 series. Python 2.6 is now in security-fix-only mode which means that there will not be a fix for it. Therefore, I close this issue. -- resolution: - fixed status: open - closed versions

[issue10436] tarfile.extractfile in r| stream mode fails with filenames or members from getmembers()

Lars Gustäbel l...@gustaebel.de added the comment: This behaviour is intentional. A tar archive does not contain a central directory structure, it is just a chain of files. As a side-effect it is possible to have multiple files with the same name in one archive, e.g. when append mode was used

[issue10369] tarfile requires an actual file on disc; a file-like object is insufficient

Lars Gustäbel l...@gustaebel.de added the comment: Hm, why don't you just do this: with stat_tarfile.open(fileobj = sys.stdout, mode = w|) as tar: for number in xrange(100): fileobj = generate_file_content(number) tarinfo = tar.gettarinfo(fileobj=open(/etc/passwd

[issue10292] tarinfo should use relative symlinks

Lars Gustäbel l...@gustaebel.de added the comment: Apparently you were in quite a hurry when you filed this bug report. - What is the exact problem and how does it manifest itself? - Any helpful details (tracebacks, output)? - Is there a testcase or example code you can provide? - Which other

[issue10261] tarfile iterator without members caching

Lars Gustäbel l...@gustaebel.de added the comment: I assume you're using Python 2.x. because tarfile's memory footprint was significantly reduced in Python 3.0, see the patch in issue2058 and r62337. This patch was not backported to the 2.x branch back then. As the 2.x branch has been closed

[issue10184] tarfile touches directories twice

Lars Gustäbel l...@gustaebel.de added the comment: I'm not entirely happy with the name of the touch argument. Apart from it being nice and short, I think it's a little too unix-y and might be misleading because it is not only about setting the modification time as the name implies, but also

[issue10184] tarfile touches directories twice

Lars Gustäbel l...@gustaebel.de added the comment: The patch goes a bit too far. Though it solves this particular problem with the way TarFile.extractall() works, it breaks TarFile.extract(). Running the testsuite does not expose this, simply because there's no testcase :-( Please see

[issue9065] tarfile: default root:root ownership is incorrect.

Lars Gustäbel l...@gustaebel.de added the comment: Fixed in r85211 (py3k), r85212 (release31-maint), r85213 (release27-maint). Thank you for the report. -- resolution: - accepted stage: - committed/rejected status: open - closed type: - behavior

[issue9071] TarFile doesn't support member files with a leading ./

Lars Gustäbel l...@gustaebel.de added the comment: This is a duplicate of issue6054 which has been fixed in Python 2.7 (r74571). (Hi, Gustavo!) -- assignee: - lars.gustaebel nosy: +lars.gustaebel resolution: - duplicate status: open - closed

[issue9065] tarfile: default root:root ownership is incorrect.

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9065

[issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath, wb)` - IOError: Is a directory

Lars Gustäbel l...@gustaebel.de added the comment: a) The point is: the operation simply wouldn't fail on a case-sensitive filesystem. There is no platform-specific or otherwise special code in TarFile.makefile(). It simply tries to extract the file and the filesystem layer says no, because

[issue8978] tarfile.ReadError: file could not be opened successfully if compiled without zlib

Lars Gustäbel l...@gustaebel.de added the comment: If you pass an explicit mode, the error message is more or less what you want: tarfile.open(uga.tgz, mode=r:gz) [...] tarfile.CompressionError: gzip module is not available The way mode=r detects which compression format is used is to open

[issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath, wb)` - IOError: Is a directory

Lars Gustäbel l...@gustaebel.de added the comment: I found the problem. As of r76780 the default for the TarFile.errorlevel argument changed from 0 (suppress errors and write them to the debug log instead) to 1 (raise exceptions for fatal extraction errors). This change was not backported

[issue8784] tarfile/Windows: Don't use mbcs as the default encoding

Lars Gustäbel l...@gustaebel.de added the comment: Maybe I'm going out on a limb here, but I think we should again consider what tarfile users on Windows(!) actually use it for under which circumstances. The following list is probably not exhaustive, but IMHO covers 90%: 1. Download tar

[issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath, wb)` - IOError: Is a directory

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8958 ___ ___ Python-bugs

[issue8958] 2.7rc1 tarfile.py: `bltn_open(targetpath, wb)` - IOError: Is a directory

Lars Gustäbel l...@gustaebel.de added the comment: Unfortunately I do not have access to an OS X machine. Is this problem specific to 2.7rc1 or are other versions affected as well? I thought the OS X filesystem was case sensitive ... -- nosy: +lars.gustaebel

[issue8833] tarfile: broken hardlink handling and testcase.

Lars Gustäbel l...@gustaebel.de added the comment: Thank you very much for this valuable report. Fixed in r81663-81666. -- resolution: - accepted status: open - closed versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker rep

[issue8741] 2.7 regression in tarfile: IOError: link could not be created

Lars Gustäbel l...@gustaebel.de added the comment: I have just committed the fix. I hope that this code is now more robust. See r81667 (trunk) and r81670 (py3k). Thank you very much for your report! -- resolution: - accepted stage: - committed/rejected status: open - closed versions

[issue8784] tarfile/Windows: Don't use mbcs as the default encoding

Lars Gustäbel l...@gustaebel.de added the comment: My expertise on Windows is rather limited, but as far as I understand the issue, I consider this a reasonable idea. I think it is impossible to find a perfect default encoding, and utf-8 seems to be the best bet with regard to portability

[issue8833] tarfile: broken hardlink handling and testcase.

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8833

[issue6715] xz compressor support

Changes by Lars Gustäbel l...@gustaebel.de: -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list

[issue5689] please support lzma compression as an extension and in the tarfile module

Changes by Lars Gustäbel l...@gustaebel.de: -- nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5689 ___ ___ Python-bugs-list

[issue8741] 2.7 regression in tarfile: IOError: link could not be created

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8741 ___ ___ Python-bugs

[issue8741] 2.7 regression in tarfile: IOError: link could not be created

Lars Gustäbel l...@gustaebel.de added the comment: @senthil: Yes, this is a platform-specific problem. The code that is failing is in fact supposed to somehow emulate symlink and hardlink extraction on platforms that don't support these, e.g. Windows. What tarfile is trying to do here

[issue8633] tarfile doesn't support undecodable filename in PAX format

Lars Gustäbel l...@gustaebel.de added the comment: I added support for the hdrcharset method and a workaround for the GNU tar bug, see r81273. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue8633] tarfile doesn't support undecodable filename in PAX format

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8633 ___ ___ Python-bugs

[issue8701] tarfile: first character of member names doubled

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8701

[issue8701] tarfile: first character of member names doubled

Lars Gustäbel l...@gustaebel.de added the comment: Unfortunately, I cannot reproduce your problem and ask you to please provide more information. Would it be possible to attach the output or a screenshot depicting the problem? Which operating system/distribution do you use? Have you double

[issue8633] tarfile doesn't support undecodable filename in PAX format

Lars Gustäbel l...@gustaebel.de added the comment: Victor, you misunderstood the pax definition, but it wouldn't harm tarfile if it knew how to handle these corrupt GNU tar archives. In the meantime I filed a bug report on bug-...@gnu.org for this. I said in msg105085 that POSIX gives

[issue8633] tarfile doesn't support undecodable filename in PAX format

Lars Gustäbel l...@gustaebel.de added the comment: I am currently working on a patch to let tarfile use the hdrcharset field. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8633

[issue8390] tarfile: use surrogates for undecode fields

Lars Gustäbel l...@gustaebel.de added the comment: I think it is a good suggestion to use surrogateescape as the default, because (I hope) it produces the fewest errors and is the best choice if tarfile is used in connection with Python's filesystem calls. - When reading tar headers

[issue8390] tarfile: use surrogates for undecode fields

Lars Gustäbel l...@gustaebel.de added the comment: Yes, I will soon have ;-) Please give me a few days... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8390

[issue8464] tarfile creates tarballs with execute permissions set

Lars Gustäbel l...@gustaebel.de added the comment: I applied the patch and added a test case (see r80616-r80619). Thanks for the report. -- resolution: - accepted stage: - committed/rejected status: open - closed ___ Python tracker rep

[issue8464] tarfile creates tarballs with execute permissions set

Lars Gustäbel l...@gustaebel.de added the comment: 0666 is the right mode and the patch is correct. @Tarek: Why does shutil.make_archive() use mode w|... instead of w:...? IMHO that is not necessary, because it works on regular files only

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel l...@gustaebel.de added the comment: Okay, it is done, see r78623 (trunk) and r78626 (py3k). Thanks to all for your work and support! -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue7232] Support of 'with' statement fo TarFile class

Changes by Lars Gustäbel l...@gustaebel.de: -- stage: patch review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7232

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel l...@gustaebel.de added the comment: Another version of the patch (issue7232.6.diff) that checks if the TarFile object is still open in the __enter__() method (plus a test for that). I removed the docstrings as Eric suggested. This is common practice in the standard library

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel l...@gustaebel.de added the comment: IMO it is okay for __enter__() and __exit__() not to have docstrings. I cannot see what's so special about the behaviour of __enter__() and __exit__(). __enter__() raises IOError only if the TarFile object has been already closed

[issue7693] tarfile.extractall can't have unicode extraction path

Lars Gustäbel l...@gustaebel.de added the comment: So, use the pax format. It stores the filenames as utf-8 and this way you will be on the safe side. I hope we both agree that the solution to your particular problem is nothing tarfile.py can provide. So, I am going to close this issue now

[issue7693] tarfile.extractall can't have unicode extraction path

Lars Gustäbel l...@gustaebel.de added the comment: In the 2.x branch tarfile is not prepared to deal with unicode pathnames at all. This changed in Python 3. The fact that it works anyway (in the majority of cases) to add filenames as unicode objects is pure coincidence - I suppose you have

[issue7693] tarfile.extractall can't have unicode extraction path

Lars Gustäbel l...@gustaebel.de added the comment: First, use a string pathname for extractall(). Most likely, your script is going to work. Convert all pathnames to strings using sys.getfilesystemencoding() before you add() them. Ensure that all systems you are going to use the archives

[issue7693] tarfile.extractall can't have unicode extraction path

Lars Gustäbel l...@gustaebel.de added the comment: I suppose you do not have a real problem here. I thought your problem was that you want to use unicode pathnames as input and output to tarfile. You don't need that. You want to transfer an archive from one system to another. You can do

[issue7693] tarfile.extractall can't have unicode extraction path

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7693

[issue7357] tarfile doesn't detect disk full error on extraction

Lars Gustäbel l...@gustaebel.de added the comment: I changed the default value for the errorlevel argument, so that fatal errors are now raised as regular exceptions by default (trunk: r76780, py3k: r76782). Thank you very much for bringing up this issue. -- resolution: - accepted

[issue6123] tarfile: opening an empty tar file fails

Lars Gustäbel l...@gustaebel.de added the comment: I have checked in a fix for this problem: trunk (r76443) and py3k (r76444). Thank you very much for your report. Sorry that it took that long to get it fixed. -- resolution: - accepted status: open - closed

[issue7357] tarfile doesn't detect disk full error on extraction

Lars Gustäbel l...@gustaebel.de added the comment: The TarFile constructor (as well as tarfile.open) takes an errorlevel keyword argument. See http://docs.python.org/dev/library/tarfile.html#tarfile-objects I quote: If errorlevel is 0, all errors are ignored when using TarFile.extract

[issue7341] test_tarfile failing (file in use when deleting) on Windows buildbots

Lars Gustäbel l...@gustaebel.de added the comment: Any idea why the 2.x buildbots aren't failing? The code is basically the same. Coincidence? The patch is okay. Still, I have attached another version of it with a slightly smaller try-except clause. Is it feasible to test if the patch actually

[issue7341] test_tarfile failing (file in use when deleting) on Windows buildbots

Lars Gustäbel l...@gustaebel.de added the comment: Alright then. I applied the change to the trunk (r76381) and py3k (r76383). What about release26-maint and release31-maint? IMO this is not necessary. -- ___ Python tracker rep...@bugs.python.org

[issue7341] test_tarfile failing (file in use when deleting) on Windows buildbots

Lars Gustäbel l...@gustaebel.de added the comment: I have always tried to be very conservative with backporting stuff that is not clearly a bugfix but alters any kind of behaviour. I am always very concerned about compatibility, especially if code has been around for as long as this code has

[issue7341] test_tarfile failing (file in use when deleting) on Windows buildbots

Lars Gustäbel l...@gustaebel.de added the comment: Mmm, chocolate... ;-) Okay, consider it done. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7341

[issue7295] test_tarfile uses a hardcoded file name

Lars Gustäbel l...@gustaebel.de added the comment: I attached a patch that uses TESTFN. Please verify that it works and then one of us checks it in. -- keywords: +patch Added file: http://bugs.python.org/file15304/issue7295.diff ___ Python tracker

[issue7232] Support of 'with' statement fo TarFile class

Lars Gustäbel l...@gustaebel.de added the comment: Please clean up the patch, and I take another look at it. -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7232

[issue4750] tarfile keeps excessive dir structure in compressed files

Lars Gustäbel l...@gustaebel.de added the comment: The latest patch (4750.gzip.basename.fix.diff) cannot be used the way it is. The problem is that it uses the name attribute to store the basename with the .gz extension stripped. This breaks compatibility

[issue4750] tarfile keeps excessive dir structure in compressed files

Lars Gustäbel l...@gustaebel.de added the comment: I fixed it in r75935 and r75937. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4750

[issue5500] tarfile: path problem in arcname under windows

Lars Gustäbel l...@gustaebel.de added the comment: I suppose this issue is related to issue4750 which I have just closed. If not, please reopen this issue. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org

[issue7101] tarfile: OSError with TarFile.add(..., recursive=True) about non-existing file

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7101

[issue6856] allow setting uid and gid when creating tar files

Lars Gustäbel l...@gustaebel.de added the comment: I applied the patch with some more small fixes to the trunk (r74750) and the py3k branch (r74751). -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue6856] allow setting uid and gid when creating tar files

Lars Gustäbel l...@gustaebel.de added the comment: TarInfo does not need set_uid() or set_gid() methods, both can be set using the uid and gid attributes. If the list of files to add to the archive is known you can do this: tar = tarfile.open(foo.tar.gz, w:gz) for filename in filenames

[issue6856] allow setting uid and gid when creating tar files

Lars Gustäbel l...@gustaebel.de added the comment: I do not quite see the benefit from the set_* methods. Although the attribute access I proposed may be slightly more complicated (because you might need the pwd and grp modules) it offers the most freedom. Let's take the set_uid() method

[issue6818] remove/delete method for zipfile/tarfile objects

Lars Gustäbel l...@gustaebel.de added the comment: -1, although I can only speak for tarfile. Removing members from a tar archive sounds obvious and easy but it is *not*. A file in an archive is stored as a header block (that contains the metadata) followed by a number of data blocks

[issue6054] tarfile normalizes arcname

Lars Gustäbel l...@gustaebel.de added the comment: I have done some research in order to find a suitable behaviour for tarfile. I wrote a script to test to what extent all the different tar implementations transform input pathnames. The results can be found at http://www.gustaebel.de/lars

[issue6254] tarfile unnecessarily requires seekable files

Lars Gustäbel l...@gustaebel.de added the comment: It is no documentation bug either: tarfile.open() is prominently featured right on the top of the first page of the tarfile module online documentation. tarfile.Tarfile() follows right after it with a short notice that tarfile.open() should

[issue6254] tarfile unnecessarily requires seekable files

Lars Gustäbel l...@gustaebel.de added the comment: tarfile.TarFile is neither unsupported nor deprecated. It is just too low-level for everyday use. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6254

[issue6254] tarfile unnecessarily requires seekable files

Lars Gustäbel l...@gustaebel.de added the comment: If I am not mistaken the functionality you look for is the streaming mode of tarfile.open(): tar = tarfile.open(fileobj=sys.stdin, mode=r|*) Does this solve your problem? -- assignee: - lars.gustaebel nosy: +lars.gustaebel

[issue6196] tarfile.extractall(readaccess=True)

Lars Gustäbel l...@gustaebel.de added the comment: I close this issue then. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6196

[issue6196] tarfile.extractall(readaccess=True)

Lars Gustäbel l...@gustaebel.de added the comment: I am still not convinced why tarfile needs this kind of a work-around built in. We talk about a very small number of cases here and the generator_tools-0.3.5.tar.gz is really broken beyond repair. It is the only thing that should be fixed here

[issue6123] tarfile: opening an empty tar file fails

Lars Gustäbel l...@gustaebel.de added the comment: Thanks for the report. Empty archives are perfectly valid and tarfile should be able to read them without error. I will take care of this issue soon. -- assignee: - lars.gustaebel nosy: +lars.gustaebel

[issue6196] tarfile.extractall(readaccess=True)

Lars Gustäbel l...@gustaebel.de added the comment: Sure, tarfile contains numerous work-arounds for quirky and buggy archives. Otherwise, it would not be usable in real-life. But we should not mix up different issues here. tarfile reads and extracts your generator_tools.tar just fine. Formally

[issue6054] tarfile normalizes arcname

Lars Gustäbel l...@gustaebel.de added the comment: So, what exactly are trying to accomplish? Why do you need that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6054

[issue6054] tarfile normalizes arcname

Lars Gustäbel l...@gustaebel.de added the comment: Apparently, the .deb file format is not explicit about that, but it seems to be common practice to have all files prefixed with './'. normpath is used all over tarfile, crucial are the occurrences in TarFile.add() and TarInfo.get_info

[issue5068] tarfile loops forever on broken input

Lars Gustäbel l...@gustaebel.de added the comment: I just checked in a fix for the problem, r70523-70527. Thank you very much for your report. -- resolution: - fixed status: open - closed versions: +Python 2.5 ___ Python tracker rep

[issue5500] tarfile: path problem in arcname under windows

Lars Gustäbel l...@gustaebel.de added the comment: At the moment, I am unable to reproduce the problem you describe. I tried several combinations of what I think you could have meant, but everything seems to work okay here. Could you please provide some stand-alone testcase or code to illustrate

[issue5151] extractall method for TarFile objects not setting owner:group on directories

Lars Gustäbel l...@gustaebel.de added the comment: This is probably a duplicate of issue1735, which was fixed in r59713, i.e. between 2.5.1 and 2.5.2. Are you by any chance using Python 2.5.1? -- assignee: - lars.gustaebel nosy: +lars.gustaebel

[issue5151] extractall method for TarFile objects not setting owner:group on directories

Lars Gustäbel l...@gustaebel.de added the comment: Could you try to do a test with the patch from issue1735? It is rather trivial to apply. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5151

[issue5151] extractall method for TarFile objects not setting owner:group on directories

Lars Gustäbel l...@gustaebel.de added the comment: Never mind! Thank you anyway for your report. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5151

[issue5068] tarfile loops forever on broken input

Changes by Lars Gustäbel l...@gustaebel.de: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5068

[issue5068] tarfile loops forever on broken input

Lars Gustäbel l...@gustaebel.de added the comment: Thanks for the report. The problem is in fact easy to reproduce. _BZ2Proxy hangs if it is passed a file object with either no data or with a partial bzipped file. For example try: tarfile.open(mode=r:bz2, fileobj=StringIO.StringIO()) I

[issue4750] tarfile keeps excessive dir structure in compressed files

Lars Gustäbel l...@gustaebel.de added the comment: Anatoly is right, the gzip file format specification (RFC 1952) says that the FNAME header field must be the basename of the original filename. So, this behaviour is not tarfile's fault but that of the gzip module and should be fixed there. 7zip

[issue4616] tarfile does not set the creation date and time of the extracted directories

Lars Gustäbel l...@gustaebel.de added the comment: I checked the necessary changes in the trunk and the py3k, release26-maint, and release30-maint branches (r67717-r67720). Thank you for your report. -- status: open - closed ___ Python tracker rep

[issue4616] tarfile does not set the creation date and time of the extracted directories

Changes by Lars Gustäbel l...@gustaebel.de: -- resolution: - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4616 ___ ___ Python-bugs-list

[issue4616] tarfile does not set the creation date and time of the extracted directories

Lars Gustäbel [EMAIL PROTECTED] added the comment: Directory times are explicitly not set. The comment in TarFile.utime() says that it is an error on Windows to use utime on directories. I am no Windows expert, so I don't know if that is still true

[issue4616] tarfile does not set the creation date and time of the extracted directories

Lars Gustäbel [EMAIL PROTECTED] added the comment: Apparently it is not. os.utime() was fixed for Windows in Python 2.5 (r45925), so it should be possible for tarfile to set directory times now. I will prepare a patch. ___ Python tracker [EMAIL PROTECTED

[issue4218] tarfile module fails to correctly parse some .tar.gz archives?!

Lars Gustäbel [EMAIL PROTECTED] added the comment: This is a known bug in Python 2.4's tarfile version (cp. issue1509889 and issue1719898). It was fixed in Python 2.5. Thank you anyway for your report. -- nosy: +lars.gustaebel resolution: - duplicate status: open - closed

[issue3838] test_tarfile error on cygwin (Directory not empty)

Lars Gustäbel [EMAIL PROTECTED] added the comment: The patch is okay. Go ahead. BTW, I've never used Cygwin before, is it always that slow? 10 minutes for a configure script on a recent machine is a real pain. -- nosy: +lars.gustaebel ___ Python

[issue3830] Tarfile has incorrect USTAR VERSION field (should be 00; is 0 NUL)

Lars Gustäbel [EMAIL PROTECTED] added the comment: This problem existed only in the first 2.5 release. -- resolution: - works for me status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3830

[issue3039] tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError

Lars Gustäbel [EMAIL PROTECTED] added the comment: Thank you very much for your patch, I applied it to the trunk as r65402. However, I decided to remove the TarFileCompat class from the Python 3.0 branch, see http://mail.python.org/pipermail/python-3000/2008-July/014448.html for details

[issue3039] tarfile.TarFileCompat.writestr(ZipInfo, str) raises AttributeError

Changes by Lars Gustäbel [EMAIL PROTECTED]: -- assignee: - lars.gustaebel nosy: +lars.gustaebel ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3039

<    1   2   3   >