Lars Gustäbel added the comment:
Closing this due to lack of interest. This is no tarfile issue. If
direct device addressing should be supported by Python, os.stat() would
be the place to implement it.
--
resolution: -> wont fix
status: open ->
New submission from Lars Gustäbel:
tarfile does not check pathnames or linknames on extraction. This can
lead to data loss or attack scenarios when members with absolute
pathnames or pathnames outside of the archive's scope overwrite or
overlay existing files or directories.
Example
Lars Gustäbel added the comment:
In principle I do not object, but this is a preliminary patch. I am
still not happy with the naming of the "check_paths" argument. Also, the
patch was made against the trunk which means that it contains hunks with
the new reStructuredText documentation.
New submission from Lars Gustäbel:
For example in tarfile.rst and logging.rst there are function
definitions using *args and/or **kwargs like:
.. function:: debug(msg[, *args[, **kwargs]])
The * and ** should be escaped IMO, so that they are not mistaken as
reStructuredText markup, which
Lars Gustäbel added the comment:
After careful consideration and a private discussion with Martin I do no
longer think that we have a security issue here. tarfile.py does nothing
wrong, its behaviour conforms to the pax definition and pathname
resolution guidelines in POSIX. There is no known or
Lars Gustäbel added the comment:
I updated the documentation, r57764 (trunk) and r57765 (2.5).
--
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Lars Gustäbel:
When rebuilding parts of the documentation the search index is emptied.
The problem is that the extensions are not stripped from the filenames
that are given to IndexBuilder.prune() method.
Therefore, the Search widget on http://docs.python.org/dev/3.0
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue12800>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel added the comment:
Attached is a patch with the current state of my work on lzma integration into
tarfile (17 test errors).
--
assignee: -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file23162/2011-09-15-tarfile-lzma.d
Lars Gustäbel added the comment:
Today I played around with lzma support for tarfile based on your last patch
(see issue5689). There are a few minor issues that I just wanted to mention, as
they break the tarfile testsuite:
- LZMAFile does not expose a name attribute. BZ2File doesn't e
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
priority: normal -> low
versions: +Python 3.3 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/i
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Lars Gustäbel added the comment:
Thanks for the report. There was a problem decoding a special and rare kind of
header field in the archive. The format of the archive is of very bad quality
BTW ;-)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -&g
Lars Gustäbel added the comment:
Some testing reveals that the bz2 module < 3.3 cannot fully decompress the file
in question. Only the first 900k are decompressed. Thus, this issue is not
related to issue13158 or the tarfile module.
--
nosy: +lars.gustae
Lars Gustäbel added the comment:
This is no bad idea. I recommend keeping it as simple as possible. I would
definitely not be supportive of a full tar clone. List, extract, create - that
should be enough. There are two possible command line choices: do what the
zipfile module does or emulate
Lars Gustäbel added the comment:
I will be happy to, but my spare time is limited right now, so this could take
about a week. If this is a problem, please go ahead.
--
___
Python tracker
<http://bugs.python.org/issue5
Lars Gustäbel added the comment:
For those who want to test it first, I post the current state of the patch
here. It is ready for commit, there are no failing tests. If nobody objects, I
will apply it this weekend.
--
Added file: http://bugs.python.org/file23880/2011-12-08-tarfile
Lars Gustäbel added the comment:
Thanks for the review, guys! I can't close this issue yet because it depends on
#6715.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
___
Python tracker
<http://bugs.python
Lars Gustäbel added the comment:
Please, go ahead!
--
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lars Gustäbel added the comment:
Is there a good reason why the tarfile mode that is used is "w|gz"? It seems to
me that this is not necessary, "w:gz" should be enough. "w|gz" is for special
operations only (see the tarfile docs).
--
nosy: +l
Lars Gustäbel added the comment:
tarfile under Python 2.x is not particularly designed to support unicode
filenames (the gzip module does not support them either), but that should not
be too hard to fix.
--
keywords: +patch
Added file:
http://bugs.python.org/file24066/tarfile-stream
Lars Gustäbel added the comment:
Just for the record:
The gzip format (defined in RFC 1952) allows storing the original filename
(without the .gz suffix) in an additional field in the header (the FNAME
field). Latin-1 (iso-8859-1) is required. It is ironic that this causes so much
trouble
Lars Gustäbel added the comment:
See http://bugs.python.org/issue11638#msg150029
--
___
Python tracker
<http://bugs.python.org/issue13639>
___
___
Python-bug
Lars Gustäbel added the comment:
Wouldn't it be better then to use a default compresslevel of 6 in tarfile? I
used level 9 in my patch without a particular reason, just because I thought 9
must be better than 6 ;-)
--
Added file: http://bugs.python.org/file24084/lzma-preset
Changes by Lars Gustäbel :
Removed file: http://bugs.python.org/file24084/lzma-preset.diff
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list m
Lars Gustäbel added the comment:
Yes, that's much better. Thanks for the tip.
--
Added file: http://bugs.python.org/file24086/lzma-preset.diff
___
Python tracker
<http://bugs.python.org/i
Lars Gustäbel added the comment:
I thought about that myself, too. It is clearly no new feature, it is really
more some kind of a fix.
Unicode pathnames given to tarfile.open() are just passed through to the open()
function, which is why this always has been working, except for this
Lars Gustäbel added the comment:
I think we should wrap this up as soon as possible, because it has already
absorbed too much of our time. The issue we discuss here is a tiny glitch
triggered by a corner-case. My original idea was to fix it in a minimal sort of
way that is backwards
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Lars Gustäbel added the comment:
You actually hit two bugs at the same time here: The target of the created
symlink was not translated from unix to windows path delimiters and is
therefore broken. The second bug is issue12926 which leads to the error in
TarFile.makefile().
Brian, AFAIK all
Lars Gustäbel added the comment:
The dereference option is only used for archive creation, so the contents of
the file a symbolic link is pointing to is added instead of the symbolic link
itself.
--
___
Python tracker
<http://bugs.python.
Lars Gustäbel added the comment:
This should be fixed now, thanks.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.python.or
Lars Gustäbel 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
<http://bugs.python.org/issue12
Lars Gustäbel added the comment:
Yes, it should be fixed in all affected branches.
--
___
Python tracker
<http://bugs.python.org/issue12841>
___
___
Python-bug
Lars Gustäbel 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 wo
Lars Gustäbel added the comment:
Issue #12841 is a duplicate of this one, but I give it precedence because it
comes with a working patch.
--
resolution: -> duplicate
status: open -> closed
versions: +Python 2.7, Python 3.3
___
Python t
Changes by Lars Gustäbel :
--
versions: +Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12841>
___
___
Python-bugs-list mailing list
Unsub
Lars Gustäbel added the comment:
Close as fixed. Thanks all!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Lars Gustäbel added the comment:
It's the low-level operating system aspects of tarfile that are very difficult
to test, e.g. filesystem and operating system dependent features such as
symbolic links, hard links, file permissions, ownership. It is not even
possible to reliably determin
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue12926>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel 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
__
Lars Gustäbel 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 the attached testc
Lars Gustäbel 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
Lars Gustäbel 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 for ne
Lars Gustäbel 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 tools are you
Lars Gustäbel 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"
Lars Gustäbel 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. That's wh
Lars Gustäbel 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: +P
Lars Gustäbel 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
Changes by Lars Gustäbel :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lars Gustäbel 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 o
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue11787>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel 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
<http://bugs.python.org/i
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue11879>
___
___
Pyth
Lars Gustäbel 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: +Python 2.6 -
Lars Gustäbel 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. In other words
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
components: +Library (Lib) -None
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issu
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue10761>
___
___
Python-bugs-lis
Lars Gustäbel 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://bugs.python.org/file20
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
With some effort I could reproduce the problem (on a FAT32 filesystem),
but what we have here is clearly a usage problem. In unpack_tarfile() in
setuptools/archive_util.py TarFile's internal _extract_member() method
is used to
Changes by Lars Gustäbel <[EMAIL PROTECTED]>:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
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
d
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
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
___
Lars Gustäbel 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
Lars Gustäbel 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.
--
Added
Lars Gustäbel 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.
This is exactl
Lars Gustäbel added the comment:
I found an issue that needs to be addressed: if there is an error while the
TarFile object is opened for writing, we cannot simply call TarFile.close() in
the __exit__() method. close() would try to finalize the archive, i.e. write
two zero end-of-archive
Lars Gustäbel 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
<http://bugs.python.org/
Changes by Lars Gustäbel :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue7232>
___
___
Python-bugs-list mai
Lars Gustäbel 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.
--
__
Lars Gustäbel 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
<http://bug
Lars Gustäbel added the comment:
Yes, I will soon have ;-) Please give me a few days...
--
___
Python tracker
<http://bugs.python.org/issue8390>
___
___
Pytho
Lars Gustäbel 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, undec
Lars Gustäbel 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 no advice on h
Lars Gustäbel added the comment:
I am currently working on a patch to let tarfile use the hdrcharset field.
--
___
Python tracker
<http://bugs.python.org/issue8
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8701>
___
___
Python-bugs-lis
Lars Gustäbel 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-checked your
Changes by Lars Gustäbel:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1531>
__
___
Python-bu
Lars Gustäbel added the comment:
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 posit
Changes by Lars Gustäbel:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1735>
__
___
Python-bu
Lars Gustäbel added the comment:
Committed to release25-maint branch as r59713.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Lars Gustäbel added the comment:
Thanks for the patch. I added a testcase and applied it to the trunk,
see r59712. Python 2.5 follows later on.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Lars Gustäbel added the comment:
I close this issue because it is out of date. The new
TarFile.extractall() method in Python 2.5 provides a way to solve the
original problem IMO.
--
resolution: -> out of date
status: open -> closed
_
Tracker &
Lars Gustäbel added the comment:
I close this issue as there has been no progress over the last 1.5 year.
--
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Lars Gustäbel added the comment:
I just did some tests and could not find any major difference. Which are
the differences you found?
BTW, in your patch the "dist" directory is not automatically created.
__
Tracker <[EMAIL PROTECTED]>
<htt
Lars Gustäbel added the comment:
Hm, on my Linux box both files are more or less identical. Sorry, I
cannot reproduce your problem.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Lars Gustäbel added the comment:
This was fixed in the trunk in r53526 about a year ago following
issue1507247. I did not backport it to 2.5 at that time, because it
would have changed existing behaviour. If there are no objections I
could do this now.
The os.mkdir() call in TarFile.makedir
Lars Gustäbel added the comment:
os.mkdir() and os.makedirs() always apply the current umask to the mode.
We cannot be responsible for poorly chosen umasks. In general, tarfile
and zipfile create directories with reasonable modes. So, IMO the
zipfile-dirperm.diff is not needed and Michael&#
Lars Gustäbel added the comment:
I took the liberty of applying my patches to the trunk (r60588) and the
release25-maint branch (r60589).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Lars Gustäbel:
tarfile.py wastes lots of memory resources. The memory consumption does
not depend on the size of an archive but on the numbers of members in it.
The attached patch reduces memory usage by about 60% and consists of two
independent strategies (each with about 30
Lars Gustäbel added the comment:
This is in fact misuse of the addfile() method on your side. The docs
(http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.addfile)
state that the first argument is supposed to be a TarInfo object not a
pathname. You should use the add() method
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
Checked into the py3k branch as r62337.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
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:
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
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
Lars Gustäbel 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
&l
Changes by Lars Gustäbel :
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue4616>
___
___
Python-bugs-list mailing list
Unsubscri
Lars Gustäbel 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 can
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue5068>
___
___
Python-bugs-lis
1 - 100 of 227 matches
Mail list logo
