[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

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

[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

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&#

[issue2004] tarfile extractall() allows local attacker to overwrite files while extracting

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/

[issue2058] reduce tarfile memory footprint

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

[issue2251] tarfile using nonexistent function

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

[issue2058] reduce tarfile memory footprint

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

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Changes by Lars Immisch <[EMAIL PROTECTED]>: -- nosy: +larsimmisch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1856> __ ___ Python-bugs

[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:

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Lars Immisch <[EMAIL PROTECTED]>: -- nosy: +larsimmisch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4073> ___ __

[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

[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

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

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

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

Changes by Lars Gustäbel : -- resolution: -> fixed ___ Python tracker <http://bugs.python.org/issue4616> ___ ___ Python-bugs-list mailing list Unsubscri

[issue4750] tarfile keeps excessive dir structure in compressed files

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

[issue5068] tarfile loops forever on broken input

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue5068> ___ ___ Python-bugs-lis

[issue5068] tarfile loops forever on broken input

Lars Gustäbel 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 will creat

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

Lars Gustäbel 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 ___ Python trac

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

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

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

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

[issue18304] ElementTree -- provide a way to ignore namespace in tags and searches

Lars Hammarstrand added the comment: Any update regarding this? We switched to lxml to make life easier but it would be useful if this functionality also was implemented in the standard library. Wishlist: 1. Flag to ignore all namespaces during find(). 2. Ability to set default namespace

[issue25278] Unexpected socket exception on SFTP 'STOR' command

Lars Schellhas added the comment: I am pretty sure that it is connected to issue 19500. And somehow that issue still isn't resolved although there are already solutions provided. -- nosy: +larsschellhas ___ Python tracker <https://bugs.py

[issue19500] ftplib: Add client-side SSL session resumption

Lars Schellhas added the comment: Excuse me, but why is this issue still open and unfixed? There are already proposed fixes and this issue has been around for nearly 7 years now. Filezilla has forwarded the responsibility to us for this issue (https://trac.filezilla-project.org/ticket/10700

[issue19500] ftplib: Add client-side SSL session resumption

Lars Schellhas added the comment: @Christian Heimes, you are absolutely right. I'm sorry if I came off rude. Actually, I just had a rough day at work with the end of it being the realisation that this missing fix would solve my day-filling issue from today. Furthermore, I'v

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue13815> ___ ___ Python-bugs-lis

[issue13935] Tarfile - Fixed GNU tar header base-256 handling

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue13935> ___ ___ Python-bugs-lis

[issue13935] Tarfile - Fixed GNU tar header base-256 handling

Lars Gustäbel added the comment: This has been fixed (issue13158, http://hg.python.org/cpython/rev/341008eab87d). Thanks anyway for the report. -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed ___ Pytho

[issue14012] Misc tarfile fixes

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel ___ Python tracker <http://bugs.python.org/issue14012> ___ ___ Python-bugs-list mailing list Un

[issue14013] tarfile should expose supported formats

Lars Gustäbel added the comment: I think this is a reasonable proposal. I think it is good style to let tarfile figure out which supported compression methods are available instead of shutil or the user. So far I have no objections. Following 3.3's crypt module, I think the name `method

[issue14056] Misc doc changes for tarfile

Lars Gustäbel added the comment: a) Good point, a case of sloppy naming. b) IMO a table is a tad too much. The amount of different compression methods is still quite small. My patch proposes a simpler approach. c) A link to shutil is very useful. BTW, thanks for the effort

[issue14012] Misc tarfile fixes

Lars Gustäbel added the comment: I updated your patch: - I removed the "import as" bit completely and changed all occurrences of _open() to builtins.open() which is more readable and explanatory. - I object to changing the error messages in the 3.2 branch due to backwards com

[issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel ___ Python tracker <http://bugs.python.org/issue14160> ___ ___ Python-bugs-list mailing list Un

[issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks

Lars Gustäbel added the comment: Thanks for the report. Attached is a patch (against 3.2) that is supposed to fix the problem. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file24735/issue14160.diff ___ Pyt

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

Changes by Lars Gustäbel : -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals

Change by Lars Beckers : -- nosy: +extmind ___ Python tracker <https://bugs.python.org/issue9338> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30438] tarfile would fail to extract tarballs with files under R/O directories (twice)

Lars Gustäbel added the comment: Actually, it is not prohibited to add the same file to the same archive more than once. -- nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue30

[issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive

Lars Gustäbel added the comment: tarfile does not use the `format` argument for reading, it will be detected. You can even mix different formats in one archive and tarfile will be fine with it. -- nosy: +lars.gustaebel ___ Python tracker <ht

[issue33741] UnicodeEncodeError onsmtplib.login(MAIL_USER, MAIL_PASSWORD)

New submission from Lars Pötter : if the password contains non ascii characters then the login fails: >>> smtObj.login(MAIL_USER, MAIL_PASSWORD) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/smtplib.py", line 720, in

[issue33741] UnicodeEncodeError onsmtplib.login(MAIL_USER, MAIL_PASSWORD)

Lars Pötter added the comment: I wanted to login to an existing account so the password works OK in Thunderbird. Here in Germany it is recommended for safe passwords to use the German umlauts(ßÄÖÜäöü). So code page 437 vs 850 or UTF-8 ? If I could pass in the bytes then I could figure out

[issue34816] ctypes + hasattr

New submission from Lars Friedrich : The following creates an OSError: import ctypes hasattr(ctypes.windll, 'test') The expected behavior would be to return "False" -- components: ctypes messages: 326528 nosy: lfriedri priority: normal severity: normal status

[issue34816] ctypes + hasattr

Lars Friedrich added the comment: Thank you for your reply. I am not sure if I understood correctly: Do you suggest to modify ctypes.__init__.py so that the __getattr__ method of LibraryLoader catches the OSError and raises an AttributeError instead, as in your example

[issue17214] http.client.HTTPConnection.putrequest encode error

Lars Ivarsson added the comment: The problem isn't the original requested url, as it is legit. The problem appears after the 302 redirect when a new (malformed) url is received from the server. There need to be some kind of check of the validity of that second url. And, preferabl

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Changes by Lars Buitinck : -- title: Allow multiple calls to multiprocessing.set_start_method -> Robustness issues in multiprocessing.{get,set}_start_method ___ Python tracker <http://bugs.python.org/issu

[issue18999] Allow multiple calls to multiprocessing.set_start_method

New submission from Lars Buitinck: The new multiprocessing based on forkserver (issue8713) looks great, but it has two problems. The first: "set_start_method() should not be used more than once in the program." The documentation does not explain what the effect of calling it twice

[issue18999] Allow multiple calls to multiprocessing.set_start_method

Changes by Lars Buitinck : -- nosy: +sbt ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Changes by Lars Buitinck : Removed file: http://bugs.python.org/file31721/mp_getset_start_method.patch ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Pytho

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: Cleaned up the patch. -- Added file: http://bugs.python.org/file31722/mp_getset_start_method.patch ___ Python tracker <http://bugs.python.org/issue18

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: In my patched version, the private popen.get_start_method gets a kwarg set_if_needed=True. popen.Popen calls that as before, so its behavior should not change, while the public get_start_method sets the kwarg to False. I realise now that this has the side

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Changes by Lars Buitinck : -- nosy: +jnoller ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: I don't really see the benefit of a context manager over an argument. It's a power user feature anyway, and context managers (at least to me) signal cleanup actions, rather than construction options. --

[issue14160] TarFile.extractfile fails to extract targets of top-level relative symlinks

Lars Gustäbel added the comment: Fixed. Thanks for the report. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

Lars Gustäbel added the comment: I did some tarfile spring cleaning: I removed the ExFileObject class completely as it was more or less a leftover from the old days. io.BufferedReader now does the job. So, as a side-effect, I close this issue as fixed. (BTW, this makes tarfile.py smaller by

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

Lars Gustäbel added the comment: In an earlier draft of my patch, I had kept ExFileObject as a subclass of BufferedReader, but I later decided against it. To use BufferedReader directly is in my opinion the cleaner solution. I admit that the change is not fully backward compatible. But a

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

Lars Gustäbel added the comment: Okay, I attached a patch that I hope we can all agree upon. It restores the ExFileObject class as a small subclass of BufferedReader as Amaury suggested. Does the documentation have to be changed, too? It states that an io.BufferedReader object is returned by

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

Lars Gustäbel added the comment: Okay, I close this issue now, as I think the problems are now resolved. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

[issue14807] Move tarfile.filemode() into stat module

Changes by Lars Gustäbel : -- nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue14807> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14810] Bug in tarfile

Lars Gustäbel added the comment: This issue is related to issue13158 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

[issue14810] Bug in tarfile

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel ___ Python tracker <http://bugs.python.org/issue14810> ___ ___ Python-bugs-list mailing list Un

[issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection

New submission from Lars Buitinck : The section "Inplace Operators" of the module docs for operator now show up in TOC at http://docs.python.org/dev/library/. I don't think that's intended as it does not describe a separate module. -- assignee: docs@python compo

[issue15328] datetime.strptime slow

New submission from Lars Nordin : The datetime.strptime works well enough for me it is just slow. I recently added a comparison to a log parsing script to skip log lines earlier than a set date. After doing so my script ran much slower. I am processing 4,784,212 log lines in 1,746 files

[issue15328] datetime.strptime slow

Lars Nordin added the comment: Running the script without any timestamp comparison (and parsing more log lines), gives these performance numbers: log lines: 7,173,101 time output: real1m9.892s user0m53.563s sys 0m1.592s -- ___ Python

[issue15858] tarfile missing entries due to omitted uid/gid fields

Lars Gustäbel added the comment: Could you provide some sample data and code? I see the problem, but I cannot quite reproduce the behaviour you describe. In all of my testcases tarfile either throws an exception or successfully reads the archive, but never silently stops. -- assignee

[issue15875] tarfile may not make @LongLink for non-ascii character

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel nosy: +lars.gustaebel versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issu

[issue15875] tarfile may not make @LongLink for non-ascii character

Lars Gustäbel added the comment: I prepared a patch that fixes this issue and adds a few tests. Please try if it works for you. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file27152/issue15875.diff ___ Pyt

[issue15950] open() should not accept bool argument

New submission from Lars Gustäbel: Today I accidentally did this: open(True).read() Passing True as a file argument to open() does not fail, because a bool value is treated like an integer file descriptor (stdout in this case). Even worse is that the read() call hangs in an endless loop on

[issue16052] Typo in "What's new in 3.3"

New submission from Lars Buitinck: I spotted a minor typo in the "What's new" for Py 3.3, introduced yesterday. See attached patch. -- assignee: docs@python components: Documentation files: typo.hg messages: 171333 nosy: docs@python, larsmans priority: normal severity

[issue16052] Typo in "What's new in 3.3"

Lars Buitinck added the comment: Sorry about the bundle, I'm an hg noob and only noticed that bundles are binary after I submitted it. Will create a regular patch next time. -- ___ Python tracker <http://bugs.python.org/is

[issue21119] asyncio create_connection resource warning

New submission from Lars Andersson: The attached code generates an unclosed socket ResourceWarning when timing out trying to connect to an unreachable address. Probably not terribly serious, but in my case, it generates distracting warnings during unit testing. I have looked briefly at the

[issue21109] tarfile: Traversal attack vulnerability

Lars Gustäbel added the comment: In the past, our answer to these kinds of bug reports has always been that you must not extract an archive from an untrusted source without making sure that it has no malicious contents. And that tarfile conforms to the posix specifications with respect to

[issue21119] asyncio create_connection resource warning

Lars Andersson added the comment: Thanks Victor, that fixes my problem. I've started using tulip/master as part of my project as that also solves other issues I have with the default asyncio of python 3.4.0, but hopefully this fix will into tulip/master as well as python 3.4.1

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: > [...] but remember, we split a volume only in the middle of a big file, not > in any other case (AFAIK). Hopefully you don't get huge pax headers or > anything strange. [...] Hopefully? Sorry, but have you tested this? I did. I let GNU ta

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: Okay, let me tell you why I reject your contribution at this point. The patch you submitted may be well-suited for your purposes but it does not meet the requirements of a standard library implementation because it is not generic and comprehensive enough. It

[issue21360] mailbox.Maildir should ignore files named with a leading dot

New submission from Lars Wirzenius: The maildir format specification (see http://cr.yp.to/proto/maildir.html) is clear that files named with leading dots should be ignore: Unless you're writing messages to a maildir, the format of a unique name is none of your business. A unique nam

[issue21369] Extended modes for tarfile.TarFile()

Lars Gustäbel added the comment: That was a design decision. What would be the advantage of having the TarFile class offer the compression itself? -- assignee: -> lars.gustaebel ___ Python tracker <http://bugs.python.org/issu

[issue21369] Extended modes for tarfile.TarFile()

Lars Gustäbel added the comment: You can pass keyword arguments to tarfile.open(), which will be passed to the TarFile constructor. You can also use pass fileobj arguments to tarfile.open(). -- ___ Python tracker <http://bugs.python.org/issue21

[issue21369] Extended modes for tarfile.TarFile()

Lars Gustäbel added the comment: Jup. That's it. -- priority: normal -> low resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.p

[issue21109] tarfile: Traversal attack vulnerability

Lars Gustäbel added the comment: Let me present for discussion a proposal (and a patch with documentation) with an approach that is a little different, but in my opinion the most effective. I hope that it will appeal to all involved. My proposal consists of a new class SafeTarFile, that is a

[issue21404] Compression level for tarfile/zipfile

Lars Gustäbel added the comment: tarfile.open() actually supports a compress_level argument for gzip and bzip2 and a preset argument for lzma compression. -- nosy: +lars.gustaebel ___ Python tracker <http://bugs.python.org/issue21

[issue21404] Compression level for tarfile/zipfile

Lars Gustäbel added the comment: That's right. But it is there. -- ___ Python tracker <http://bugs.python.org/issue21404> ___ ___ Python-bugs-list m

[issue2943] Distutils should generate a better error message when the SDK is not installed

Lars H added the comment: +1 vote for fixing this problem. Matt Hickford said it very well... the error message is very cryptic, not giving the user a clue as to what domain the problem lies in. -- nosy: +Lars.H ___ Python tracker <h

[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction

Lars Buitinck added the comment: Any reason why this issue is still open? I just got a lot of compiler warnings when building Numpy, so this isn't just relevant to C++ programmers. (Btw., I did RTFM: the issue's Resolution is "accepted" but that option is not documente

[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction

Lars Buitinck added the comment: Redid the patch. -- Added file: http://bugs.python.org/file28653/constness.patch ___ Python tracker <http://bugs.python.org/issue9

[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction

Lars Buitinck added the comment: Oops, forgot to save changes to Doc/c-api/object.rst. PyObject_CallMethodObjArgs takes a PyObject*, mustn't that be non-const for reference counting to work? PyDict_GetItemString already has const, just not in refcounts.dat. Fixed. -- Added file:

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: Ok. Do you (or jnoller?) have time to review my proposed patch, at least before 3.4 is released? I didn't see it in the release schedule, so it's probably not planned soon, but I wouldn't want the API to change

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: > BTW, the context objects are singletons. I haven't read all of your patch yet, but does this mean a forkserver will be started regardless of whether it is later used? That would be a good thing, since starting the fork server after reading in la

[issue18999] Robustness issues in multiprocessing.{get, set}_start_method

Lars Buitinck added the comment: Ok, great. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18999] Support different contexts in multiprocessing

Lars Buitinck added the comment: Thanks, much better than my solution! -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18999> ___ _

[issue18999] Support different contexts in multiprocessing

Lars Buitinck added the comment: Strange, I can't actually get it to work: >>> from multiprocessing import Pool, get_context >>> forkserver = get_context('forkserver') >>> Pool(context=forkserver) Traceback (most recent call last): File "&qu

[issue18999] Support different contexts in multiprocessing

Lars Buitinck added the comment: I also tried from multiprocessing.pool import Pool but that died with ImportError: cannot import name get_context -- ___ Python tracker <http://bugs.python.org/issue18

[issue17153] tarfile extract fails when Unicode in pathname

Lars Gustäbel added the comment: IIRC, tarfile under 2.7 has never been explicitly unicode-safe, support for unicode objects is heterogeneous at best. The obvious work-around is to work exclusively with str objects. What we can't do is to decode the utf-8 pathname from the archive

[issue16859] tarfile.TarInfo.fromtarfile does not check read() return value

Lars Gustäbel added the comment: The size of the buffer returned by TarInfo.fromtarfile() is checked by TarInfo.frombuf() which raises either an EmptyHeaderError or TruncatedHeaderError respectively. -- assignee: -> lars.gustaebel resolution: -> not a bug stage: -> resolv

[issue21987] TarFile.getmember on directory requires trailing slash iff over 100 chars

Lars Gustäbel added the comment: Apparently, the problem is located in TarInfo._proc_gnulong(). I attached a patch. When tarfile reads an archive, it strips trailing slashes from all filenames, except GNUTYPE_LONGNAME headers, which is a bug. tarfile creates GNU_FORMAT tar files by default

[issue22208] tarfile can't add in memory files (reopened)

Lars Gustäbel added the comment: Why overcomplicate things? import io, tarfile with tarfile.open("foo.tar", mode="w") as tar: b = "hello world!".encode("utf-8") t = tarfile.TarInfo("helloworld.txt") t.size = len(b) # this is crucia

[issue22208] tarfile can't add in memory files (reopened)

Lars Gustäbel added the comment: tarfile needs to know the size of a file object beforehand because the tar header is written first followed by the file object's data. If the file object is not based on a real file descriptor, tarfile cannot simply use os.fstat() but the user has to pas

[issue22208] tarfile can't add in memory files (reopened)

Lars Gustäbel added the comment: I don't have an idea how to make it easier and still meet all/most requirements and without cluttering up the api. The way it currently works allows the programmer to control every tiny aspect of a tar member. Maybe it's best to simply add a new en

[issue22208] tarfile can't add in memory files (reopened)

Lars Gustäbel added the comment: Please provide a patch which allows easy addition of file-like objects (not only io.BytesIO) and directories, preferably hard and symbolic links, too. It would be nice to still be able to change attributes of a TarInfo before addition. Please also add tests

[issue22565] missing const in declaration of PyErr_WarnEx in C-API docs

New submission from Lars Buitinck: The declaration for PyErr_WarnEx in Doc/c-api/exceptions.rst is missing a const compared to Include/warnings.h. -- assignee: docs@python components: Documentation files: pyerr_warnex_const.patch keywords: patch messages: 228657 nosy: docs@python

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: I cannot yet go into the details, because I have not tested the patch. The comments, docstrings and quoting are not very consistent with the rest of the module. There are a few spelling mistakes. The open_volume() method is more or less a copy of the open

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: At first, I'd like to take back my comment on this patch being too complex for too little benefit. That is no real argument. Okay, I gave it a shot and I have a few more remarks: The patch does not support iterating over a multi-volume tar archive, e.g

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: I had the following idea: What about a separate class, let's call it TarVolumeSet for now, that maps a set of (virtual) volumes onto one big file-like object. This TarVolumeSet will be passed to a TarFile constructor as the fileobj argument. It is subclas

[issue18321] Multivolume support in tarfile module

Lars Gustäbel added the comment: > It's also consistent with how the tar command works afaik, just listing the > contents of the current volume. No, GNU tar operates on the entirety of the archive and asks for the filename of the subsequent volume every time it hits eof in the cur

<    1   2   3   >