Lars Gustäbel 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/tarfile/wwgtd.html.
My
Lars Gustäbel 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 (that contain the file&#
Lars Gustäbel 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
Lars Gustäbel 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 as an example
Lars Gustäbel 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
<http://bugs.python.org/
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue7101>
___
___
Python-bugs-lis
Lars Gustäbel added the comment:
Please clean up the patch, and I take another look at it.
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/iss
Lars Gustäbel 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
Lars Gustäbel added the comment:
I fixed it in r75935 and r75937.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Lars Gustäbel 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
<http://bugs.python.org/
Lars Gustäbel 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
<h
Lars Gustäbel 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 solve
Lars Gustäbel 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
<http://bugs.python.org/issue7
Lars Gustäbel 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.
But as I don't
Lars Gustäbel added the comment:
Mmm, chocolate... ;-)
Okay, consider it done.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Lars Gustäbel 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(). Nevertheless,
Lars Gustäbel 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 ->
Lars Gustäbel 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
status: o
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue7693>
___
___
Python-bugs-lis
Lars Gustäbel 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 a utf-8 system
Lars Gustäbel 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 on have the same
Lars Gustäbel 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 that
with ta
Changes by Lars Yencken :
--
nosy: +lars512
___
Python tracker
<http://bugs.python.org/issue1676>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lars Gustäbel 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
that issue
Lars Gustäbel 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
<http://bugs.python.org/
Lars Gustäbel added the comment:
So, what exactly are trying to accomplish? Why do you need that?
--
___
Python tracker
<http://bugs.python.org/issue6
Lars Gustäbel 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(). As you'
Lars Gustäbel 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 IMO ;-)
I agree
Lars Gustäbel 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
___
Pyt
Lars Gustäbel 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, the data is okay
Lars Gustäbel added the comment:
I close this issue then.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Lars Gustäbel 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: +l
Lars Gustäbel added the comment:
tarfile.TarFile is neither unsupported nor deprecated. It is just too
low-level for everyday use.
--
___
Python tracker
<http://bugs.python.org/issue6
Lars Gustäbel 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 better be used
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8633>
___
___
Python-bugs-list mailing list
Unsubscri
Lars Gustäbel 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
<http://bugs.python.org/
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8741>
___
___
Python-bugs-list mailing list
Unsubscri
Lars Gustäbel 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 is to e
Changes by Lars Gustäbel :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Lars Gustäbel :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8833>
___
___
Python-bugs-lis
Lars Gustäbel 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. IIRC most of the
Lars Gustäbel 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
<http://bugs.p
Lars Gustäbel 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: +P
Lars Gustäbel 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 archives f
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8958>
___
___
Python-bugs-list mailing list
Unsubscri
Lars Gustäbel 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
Lars Gustäbel 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 to the 2.6 branch
Lars Gustäbel 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 compres
Lars Gustäbel 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 it believes
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue9065>
___
___
Python-bugs-lis
Lars Gustäbel 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
___
Pytho
Lars Gustäbel added the comment:
The question is what you're trying to accomplish. If you just want to prevent
tarfile from stopping at the first invalid header in order to extract
everything following it, you may use the ignore_zeros=True keyword arg
Lars Gustäbel added the comment:
After all these years, it is not that easy to say why the decision to swallow
this exception was made. One part surely was a lack of experience with the tar
format itself and all of its implementations. The other part I guess was that
it was supposed to avoid
Lars Buitinck added the comment:
I'm sorry, I really don't understand this refcounts.dat file and I'm not going
to hack it further. Does the patch as it currently stands solve the issue with
CallMethod and CallFunction, or not? (It has the chan
Lars Gustäbel added the comment:
I'd like to re-emphasize that it is best to keep the whole thing as simple and
straight-forward as possible. Offer some basic operations and that's it.
Although I am pretty accustomed to the original tar command line, I think we
should copy zipfile&#
New submission from Lars Buitinck:
PySequence_List has accepted iterables since changeset 6c82277e77f3 of May 1,
2001 ("NEEDS DOC CHANGES" :), but its documentation still only speaks of
sequences. I suggest that it is changed to promise to handle arbitrary
iterables,
Lars Gustäbel added the comment:
I would argue that a serious alternative to this patch is to simply override
the TarFile.chown() method in a subclass. However, I'm not sure if this expects
too much of the user.
--
___
Python tracker
Lars Gustäbel added the comment:
I have written a test for the issue, so that we have a basis for discussion.
There are four different scenarios where an unexpected eof can occur: inside a
metadata block, directly after a metadata block, inside a data segment or
directly after a data segment
Lars Gustäbel added the comment:
@Martin:
Yes, that's right, but only for cases where the TarFile.fileobj attribute is an
actual file object. But, most of the time it is something special, e.g.
GzipFile or sys.stdin, which makes random seeking either impossible or perform
very badly.
Changes by Lars Gustäbel :
Added file: http://bugs.python.org/file39544/issue24259-2.x.diff
___
Python tracker
<http://bugs.python.org/issue24259>
___
___
Python-bug
Lars Gustäbel added the comment:
@Thomas:
I think your proposal adds a little too much complexity. Also, ExFileObject is
not used during iteration, and we would like to detect broken archives without
unpacking all the data segments first.
I have written patches for Python 2 and 3
Lars Gustäbel added the comment:
@Martin:
This is actually a nice idea that I hadn't thought of. I updated the Python 3
patch to use a seek() that moves to one byte before the next header block,
reads the remaining byte and raises an error if it hits eof. The code looks
rather clean com
Changes by Lars Gustäbel :
Added file: http://bugs.python.org/file39580/issue24259-2.x-2.diff
___
Python tracker
<http://bugs.python.org/issue24259>
___
___
Python-bug
Lars Gustäbel added the comment:
You don't need to patch the tarfile module. You could use os.walk() in
shutil._make_tarball() and add each file with TarFile.add(recursive=False).
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.py
Lars Gustäbel added the comment:
The patch would change behaviour for all tarfile users by the back door, that's
why I am a little reluctant. And if the same can be achieved by a reasonably
simple change to shutil I think it's ju
Lars Gustäbel added the comment:
The problem is that the tar archive has empty uid and gid fields, i.e. 7 spaces
terminated with a null-byte.
I attached a patch that solves the problem.
--
keywords: +patch
Added file: http://bugs.python.org/file39815/issue24514.diff
Lars Gustäbel added the comment:
You're welcome :-D
--
assignee: -> lars.gustaebel
priority: normal -> low
stage: -> patch review
type: -> behavior
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.p
Lars Gustäbel added the comment:
Yes, Python 2.7 still gets bugfixes.
However, there's still some work to do on the patch (maybe clean the code,
write a test, add a NEWS entry).
--
___
Python tracker
<http://bugs.python.org/is
Lars Gustäbel added the comment:
I think a simple addition to the existing unittest for nti() will be enough.
itn() seems well-tested, and nts() and stn() are not affected, because they
don't operate on numbers.
--
Added file: http://bugs.python.org/file39832/issue24514
Lars Gustäbel added the comment:
Martin, I followed your suggestion to raise ReadError. This needed an
additional change in copyfileobj() because it is used both for adding file data
to an archive and extracting file data from an archive.
But I think the patch is in good shape now
Changes by Lars Gustäbel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Lars Gustäbel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Lars Gustäbel added the comment:
Thanks for the detailed report and the patch. I haven't checked yet, but I
suppose that the entire 3.x branch is affected. The first thing I have to do
now is to come up with a comprehensive testcase.
--
assignee: -> lars.gustaebel
co
Changes by Lars Gustäbel :
--
resolution: -> fixed
stage: test needed -> resolved
status: open -> closed
versions: -Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.or
Lars Gustäbel added the comment:
Closing after six years of inactivity.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Lars Gustäbel added the comment:
Sorry for the glitch, I suppose everything works fine now.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Lars Gustäbel added the comment:
Closed after years of inactivity.
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
Lars Gustäbel added the comment:
Please give us some example test code that shows us what goes wrong exactly.
--
___
Python tracker
<http://bugs.python.org/issue26
Lars Gustäbel added the comment:
TarFile.makelink() has a fallback mode in case the platform does not support
links. Instead of a symlink or a hardlink it extracts the file it points to as
long as it exists in the current archive.
More precisely, makelink() calls os.symlink() and if one of
Lars Gustäbel added the comment:
I suck :-) It is hg revision bb94f6222fef.
--
___
Python tracker
<http://bugs.python.org/issue23228>
___
___
Python-bugs-list m
Lars Gustäbel added the comment:
I agree with David that there is no need for tarfile to be thread-safe. There
is nothing to be gained from distributing one TarFile object among multiple
threads because it operates on a single resource which has to be accessed
sequentially anyway. So, it
Lars van Gemerden added the comment:
I was not aware the __name__ attribute is an implementation detail. It is
described in the docs: https://docs.python.org/3/reference/datamodel.html.
I have been using it since python 2.7, for example for logging.
The function “split_module_names” is just
201 - 283 of 283 matches
Mail list logo
