[issue523020] pickle/cPickle Inconsistent EOF handling

Change by admin : -- github: None -> 36163 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue402868] fileobject.c:get_line leaks memory when hitting EOF

Change by admin : -- github: None -> 33602 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue420502] seek/tell beyond eof without exceptions

Change by admin : -- github: None -> 3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue402868] fileobject.c:get_line leaks memory when hitting EOF

Change by admin : -- github: None -> 33602 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40251] selectors.KqueueSelector hangs on EOF, unlike other selectors

Andrew Svetlov added the comment: Using selectors with blocked files looks weird at least. Should we care? -- ___ Python tracker ___

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

Martin Panter added the comment: Looks like the same as Issue 32917. I presume there are two newlines at the end of the file because there are two newlines following every config section. IMO this is a minor cosmetic annoyance, just like writing a key with an empty value gets you a trailing

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

Eric V. Smith added the comment: Please provide code that we can run that shows the problem. -- nosy: +eric.smith ___ Python tracker ___

[issue45349] configparser.ConfigParser: 2 newlines at end of file (EOF)

severity: normal status: open title: configparser.ConfigParser: 2 newlines at end of file (EOF) type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

Change by Terry J. Reedy : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

Pablo Galindo Salgado added the comment: I concur with Terry, ending a file with *is* a syntax error. -- ___ Python tracker ___

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg402911 ___ Python tracker ___ ___ Python-bugs-list

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

Pablo Galindo Salgado added the comment: I concur -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

Terry J. Reedy added the comment: I believe that this should be closed as not-a-bug. Ending a file with *is* a syntax error. Previous, it was assumed that the problem, in retrospect, was the 'extra' indent. But one can equally say that the problem is the 'missing' statement after the

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

"" compile(string, "", "single") == Traceback (most recent call last): File "/home/xxm/Desktop/IFuzzer/test/test1.py", line 304, in compile(string, "", "single")

[issue34371] File reading gets stuck if you read at eof on macos

Change by Irit Katriel : -- stage: -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue3014] file_dealloc() assumes errno is set when EOF is returned

Change by Irit Katriel : -- stage: patch review -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue3014] file_dealloc() assumes errno is set when EOF is returned

Irit Katriel added the comment: I believe this is out of date - there is no longer file_dealloc or anything similar to the code in the report in fileobject.c -- nosy: +iritkatriel resolution: -> out of date status: open -> pending ___ Python

[issue28462] subprocess pipe can't see EOF from a child in case of a few children run with subprocess

Change by Eryk Sun : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Pablo Galindo Salgado added the comment: Closing as "not a bug" as per the previous discussion. If someone sees new information here, please, feel free to re-open. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Pablo Galindo Salgado added the comment: Yeah, I also believe this doesn't look like a bug and the fact that is consistent with 3.8 makes me more confident to say that is not. -- ___ Python tracker

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Lysandros Nikolaou added the comment: I can't really understand if this should be considered a bug or not. It's definitely consistent with 3.8 and my inclination that it is not. -- nosy: +pablogsal ___ Python tracker

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

Change by Guido van Rossum : -- nosy: +lys.nikolaou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42919] Blank in multiline “if expressions” will lead to EOF errors

unexpected) === snippet =""" if True: a = 1 """ compile(snippet, "", "single") === Traceback (most recent call last): File "/home/xxm/Desktop/nameChanging/report/test1.py", line 1,

[issue42813] Extra spaces cause unexpected EOF error in "compile" function with mode "single"

New submission from Xinmeng Xia : Running the following program will lead to an unexpected EOF error. If we delete the space before triple-quotation mark("""), the error will gone. If we replace the content of snippet with "a = 1", the program will work well

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Change by Benjamin Peterson : -- resolution: -> out of date stage: test needed -> resolved status: pending -> closed ___ Python tracker ___

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Irit Katriel added the comment: Since this is a python 2 only issue, should this issue be closed as out of date? -- nosy: +iritkatriel status: open -> pending ___ Python tracker

[issue1706039] Added clearerr() to clear EOF state

Change by Serhiy Storchaka : -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40251] selectors.KqueueSelector hangs on EOF, unlike other selectors

ty: normal status: open title: selectors.KqueueSelector hangs on EOF, unlike other selectors versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40251> ___ ___

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

Change by Roundup Robot : -- pull_requests: +16584 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17074 ___ Python tracker ___

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

The issue that I have is if the command you enter is 'EOF' (or 'EOF --some --arg'), you end up calling your do_EOF function. I think this unintended side effect could be avoided if the check for EOFError was removed and the exception was just raised. (see https://github.com/python/cpython/blob

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

Aldwin Pollefeyt added the comment: The EOF mentioned in msg309788 is the first reason why I searched in the library code for a solution. Then saw it as an opportunity to create hidden functions in the shell. So I created issue37030 [0] and PR13536 [1]. Later got notified about this thread

[issue34566] pipe read sometimes returns EOF but returncode is still None

Martin Panter added the comment: You probably only need to call "wait" once. That blocks the thread until it gets a result, so it is more CPU-efficient than calling "poll" in a busy loop. Since you open a separate pipe for "stderr" in script.py, but don't do anything with it, there could be

[issue34566] pipe read sometimes returns EOF but returncode is still None

pmoravec added the comment: > The "poll" method does not wait for the child to exit. Normally you use the > "wait" method in this situation. I suspect this is a bug in the application, > not in Python. Thanks for clarification. Could you please confirm what code change in that script is

[issue34566] pipe read sometimes returns EOF but returncode is still None

Martin Panter added the comment: The "grep" process may be closing its end of the pipe before it exits. Or if Grep leaves the pipe open when it exits, the OS may close the pipe before it makes the child exit status available. Either way, I suspect "p.stdout.read()" returns an empty string

[issue34566] pipe read sometimes returns EOF but returncode is still None

Change by Marcel Plch : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34566] pipe read sometimes returns EOF but returncode is still None

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34566] pipe read sometimes returns EOF but returncode is still None

Marcel Plch added the comment: original downstream issue - https://bugzilla.redhat.com/show_bug.cgi?id=1623070 -- title: pipe read sometimmes returns EOF but returncode is still None -> pipe read sometimes returns EOF but returncode is still N

[issue34566] pipe read sometimmes returns EOF but returncode is still None

New submission from Marcel Plch : TL;DR: For reproducer, please see attached file and the end of this description for a runner script. It seems that when pipe is being read it has a chance of returning EOF and not setting the return code. This bug affects all (or at least a broad set

[issue34371] File reading gets stuck if you read at eof on macos

Change by Ronald Oussoren : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34371] File reading gets stuck if you read at eof on macos

Ronald Oussoren added the comment: For completeness sake I've attached a C program demonstrating the same problem. -- status: pending -> open Added file: https://bugs.python.org/file47740/readwrite.c ___ Python tracker

[issue34371] File reading gets stuck if you read at eof on macos

Ronald Oussoren added the comment: This is IMHO not a bug in CPython (or even macOS). On Python 2.7 file I/O is implemented using C's stdio library and that prescribes this behaviour (the "at EOF" state of a file stream is sticky. fd.seek(0, 2) should unset the &qu

[issue34371] File reading gets stuck if you read at eof on macos

New submission from Sverrir Berg : Reading a file that is at eof causes the file reading to halt indefinitely. 1) open() a file and read() everything from it. 2) call read() a second time - reading nothing (this causes the issue). 3) append to the file (using another file handle or manually). 4

[issue3014] file_dealloc() assumes errno is set when EOF is returned

Change by Sanyam Khurana : -- keywords: +patch pull_requests: +5849 stage: -> patch review ___ Python tracker ___

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

Change by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___

[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)

Daniel <dbk...@gmail.com> added the comment: If you write a handler for EOF like so: from cmd import Cmd class FooShell(Cmd): def do_EOF(self, args): # exit on EOF raise SystemExit() shell = FooShell() shell.cmdloop() Then when running the shel

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

STINNER Victor added the comment: FYI The bug has been fixed in the Sphinx development branch (HEAD of master): https://github.com/sphinx-doc/sphinx/issues/4061#issuecomment-330140975 I validated that Sphinx master now works as expected on Python 2.7.14. --

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

Benjamin Peterson added the comment: wontfixing since Sphinx has fixed their code. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

Benjamin Peterson added the comment: This seems like a bug, or least poor design, in Sphinx. It tries to read from pipes from processes that it knows are already dead (because it joined them!). -- ___ Python tracker

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

Changes by STINNER Victor : -- nosy: +pitrou ___ Python tracker ___ ___

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

STINNER Victor added the comment: Using git bisect, I identified that Sphinx started to fail since the commit 12536bd261ba95cd2748f3d7d47768742a6ffa7a which comes from bpo-30775. I reported the bug to Sphinx: https://github.com/sphinx-doc/sphinx/issues/4061 -- nosy: +haypo

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

Changes by STINNER Victor : -- nosy: +benjamin.peterson priority: normal -> release blocker ___ Python tracker ___

[issue31016] [Regression] sphinx shows an EOF error when using python2.7 from the trunk

New submission from Matthias Klose: [forwarded from https://bugs.debian.org/869098 and] sphinx shows an EOF error when using python2.7 from the trunk. Last successful build was with the 2.7.13 release. It looks like this is triggered only when using the parallel mode in sphinx. I haven't

[issue29717] `loop.add_reader` and `<<EOF`

= asyncio.get_event_loop() main_loop.run_until_complete(main(main_loop)) ``` When I run it by: ```bash $ ./stdin_issue.py < hello > EOF ``` I get: ``` Traceback (most recent call last): File "/usr/lib/python3.5/asyncio/selector_events.py", line 234, in add_reader key = self._sel

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Jun Wu added the comment: haypo: The file.__iter__ EINTR issue may be better discussed as a separate bug report. It's not related to stdin or EOF or Windows. Since we have some EINTR fixes for Python 2.7.4, I think it's reasonable to fix the remaining EINTR issues for 2.7.13+. If I have read

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

STINNER Victor added the comment: I don't see any simple solution to get a 100% reliable I/O stack on Python 2. Python 3.5 contains a pure Python implementation of the io module: _pyio.FileIO uses os.read() and os.write(). In Python 3.4 and older, the _pyio still used io.FileIO (implemented

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

STINNER Victor added the comment: Martijn Pieters: Sadly, Python 2 I/O are full of bugs in corner cases :-/ First of all, in most cases, Python 2 uses the libc for I/O, but the libc has known bugs including segfaults:

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Martijn Pieters added the comment: It looks like readahead was missed when http://bugs.python.org/issue12268 was fixed. -- ___ Python tracker ___

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Martijn Pieters added the comment: This bug affects all use of `file.__iter__` and interrupts (EINTR), not just sys.stdin. You can reproduce the issue by reading from a (slow) pipe in a terminal window and resizing that window, for example; the interrupt is not handled and a future call ends

[issue28462] subprocess pipe can't see EOF from a child in case of a few children run with subprocess

Eryk Sun added the comment: Due to a race condition, the Popen call in the second process is inadvertently inheriting the handle for the write end of the pipe that's created for the first process. Thus stdout.readline() in the first thread doesn't see EOF until that handle is closed

[issue28462] subprocess pipe can't see EOF from a child in case of a few children run with subprocess

Changes by Martin Panter : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___

[issue28462] subprocess pipe can't see EOF from a child in case of a few children run with subprocess

also create reader helper thread which reads on a pipe from the child. All is working correctly while I have only one worker thread and run only one child. When the child finishes the reader helper thread gets EOF and exits. But when I have two worker threads and run two children, a pipe from early

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: I've committed a minimal variation - thanks for the patches. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker

[issue26807] mock_open()().readline() fails at EOF

Roundup Robot added the comment: New changeset cbb31b2a3dba by Robert Collins in branch '3.5': Issue #26807: mock_open 'files' no longer error on readline at end of file. https://hg.python.org/cpython/rev/cbb31b2a3dba New changeset 72a798e27117 by Robert Collins in branch 'default': Issue

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: So something like for line in _state[0]: yield line while True: yield '' Will probably do it just fine. -- ___ Python tracker

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: Actually, further inspection and a teddybear with Angus Lees uncovers this: diff --git a/Lib/unittest/test/testmock/testmock.py b/Lib/unittest/test/testmock/testmock.py --- a/Lib/unittest/test/testmock/testmock.py +++ b/Lib/unittest/test/testmock/testmock.py

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: ./python Lib/unittest/test/testmock/testmock.py ..s. -- Ran 80 tests in 0.180s OK (skipped=1) So thats great. I am

[issue26807] mock_open()().readline() fails at EOF

Yolanda added the comment: How about... @@ -2339,9 +2339,12 @@ def mock_open(mock=None, read_data=''): if handle.readline.return_value is not None: while True: yield handle.readline.return_value -for line in _state[0]: -yield line +

[issue26807] mock_open()().readline() fails at EOF

Yolanda added the comment: I tried patching the readline_side_effect call. But i cannot trap StopIteration there, and i don't see any clear way to detect that the generator has reached its end at that level. -- ___ Python tracker

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: You're changing _mock_call but readline is actually implemented in _readline_side_effect - just changing that should be all thats needed (to deal with StopIteration). You will however need to fixup the return values since the test I added is a bit wider than

[issue26807] mock_open()().readline() fails at EOF

Yolanda added the comment: So... the failures are because i'm capturing the StopIteration exception in that case. then it's normal that it's not raised. How should you solve that problem instead? -- ___ Python tracker

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: Thanks Yolanda. I've touched up the test a little and run a full test run (make test) - sadly it fails: there is an explicit test that StopIteration gets raised if you set it as a side effect.

[issue26807] mock_open()().readline() fails at EOF

Yolanda added the comment: diff --git a/Lib/unittest/test/testmock/testwith.py b/Lib/unittest/test/testmock/testwith.py index a7bee73..efe6391 100644 --- a/Lib/unittest/test/testmock/testwith.py +++ b/Lib/unittest/test/testmock/testwith.py @@ -297,5 +297,16 @@ class

[issue26807] mock_open()().readline() fails at EOF

Robert Collins added the comment: Thanks Yolanda, that looks sane - could you perhaps add a test for this in Lib/unittest/tests/test_mock/ ? -- ___ Python tracker

[issue26807] mock_open()().readline() fails at EOF

Yolanda added the comment: diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py index 7400fb7..9e47cd2 100644 --- a/Lib/unittest/mock.py +++ b/Lib/unittest/mock.py @@ -991,7 +991,10 @@ class CallableMixin(Base): raise effect if not _callable(effect): -

[issue26807] mock_open()().readline() fails at EOF

) StopIteration -- components: Library (Lib) messages: 263814 nosy: rbcollins priority: normal severity: normal stage: test needed status: open title: mock_open()().readline() fails at EOF type: behavior versions: Python 3.5, Python 3.6 ___

conda: Fetching package metadata: SSL verification error: EOF occurred in violation of protocol (_ssl.c:645)

Hi all, I use the latest conda, ie, Anaconda3-4.0.0-Linux-x86_64 to install some packages, but always meet the following error: $ conda install conda-build Using Anaconda Cloud api site https://api.anaconda.org Fetching package metadata: SSL verification error: EOF occurred in violation

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

Changes by Berker Peksag : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue5505] sys.stdin.read() doesn't return after first EOF on Windows

Martin Panter added the comment: Since this was apparenly only a bug in 3.2, can we close it as being out of date? -- nosy: +martin.panter ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Roundup Robot added the comment: New changeset 88d6742aa99a by Serhiy Storchaka in branch '2.7': Issue #15068: Avoid creating a reference loop in fileinput. https://hg.python.org/cpython/rev/88d6742aa99a New changeset a0de41b46aa6 by Serhiy Storchaka in branch '3.5': Issue #15068: Avoid

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: Ah, thanks Martin. I forgot that assigning an attribute to a bound method creates a reference loop. This can be fixed without performance lost by using a clever trick. -- ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Martin Panter added the comment: It seems this change is causing some (intermittent?) buildbot failures in 2.7: http://buildbot.python.org/all/builders/s390x%20RHEL%202.7/builds/273/steps/test/logs/stdio == FAIL: test_saveall

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: Committed in changesets 5fbd16326353 (2.7), 9ead3a6c5f81 (3.5), and fefedbaac640 (default). Due to SMTP failure there is no Roundup report. Warnings are not emitted in maintained releases. -- resolution: -> fixed stage: patch review -> resolved

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: Ping. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Don Hatch added the comment: I've reported the unfriendly input withholding that several people have observed and mentioned here as a separate bug: http://bugs.python.org/issue26290 . The symptom is different but I suspect it has exactly the same underlying cause (incorrect use of stdio) and

[issue1633941] for line in sys.stdin: doesn't notice EOF the first time

Dan Kegel added the comment: Still present in python 2.7.9, but fixed in python 3.4.3. Also, in python 3.4.3, output is immediate, there seems to be no input buffering. -- nosy: +dankegel ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: > It's more a question of whether the entire change is appropriate for 2.7. What is your answer? To me there is a bug and we can fix it. -- ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Benjamin Peterson added the comment: That individually is probably okay. It's more a question of whether the entire change is appropriate for 2.7. Note PendingDeprecationWarning is fairly useless, since it's rarely enabled. On Sat, Dec 19, 2015, at 00:34, Serhiy Storchaka wrote: > > Serhiy

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: Benjamin, is it good to add PendingDeprecationWarning in 2.7? -- nosy: +benjamin.peterson versions: -Python 3.4 ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Changes by Kristján Valur Jónsson : -- nosy: -kristjan.jonsson ___ Python tracker ___

[issue15068] fileinput requires two EOF when reading stdin

Changes by Serhiy Storchaka : -- versions: +Python 2.7 Added file: http://bugs.python.org/file41226/fileinput_no_buffer-2.7.patch ___ Python tracker

[issue15068] fileinput requires two EOF when reading stdin

Changes by Serhiy Storchaka : -- nosy: +gvanrossum ___ Python tracker ___ ___

[issue15068] fileinput requires two EOF when reading stdin

Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file41224/fileinput_no_buffer.patch ___ Python tracker ___

[issue15068] fileinput requires two EOF when reading stdin

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file41225/fileinput_no_buffer.patch ___ Python tracker ___

[issue15068] fileinput requires two EOF when reading stdin

Serhiy Storchaka added the comment: Using readlines() instead of readline() was added in 4dbbf322a9df for performance. But it looks that now this is not needed. Naive implementation with readline() is about 2 times slower, but with careful optimization we can achieve the same performance (or

[issue24259] tar.extractall() does not recognize unexpected EOF

Changes by Lars Gustäbel l...@gustaebel.de: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24259 ___

[issue24259] tar.extractall() does not recognize unexpected EOF

Roundup Robot added the comment: New changeset 372aa98eb72e by Lars Gustäbel in branch '2.7': Issue #24259: tarfile now raises a ReadError if an archive is truncated inside a data segment. https://hg.python.org/cpython/rev/372aa98eb72e New changeset c7f4f61697b7 by Lars Gustäbel in branch

[issue24259] tar.extractall() does not recognize unexpected EOF

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.

[issue24259] tar.extractall() does not recognize unexpected EOF

Martin Panter added the comment: From the current documentation and limited experience with the module, ReadError (or a subclass) sounds best. I would only expect OSError only for OS-level things, like file not found, disk error, etc. The patches look good. One last suggestion is to use

[issue24259] tar.extractall() does not recognize unexpected EOF

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 compared

[issue24259] tar.extractall() does not recognize unexpected EOF

Changes by Lars Gustäbel l...@gustaebel.de: Added file: http://bugs.python.org/file39580/issue24259-2.x-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24259 ___

  1   2   3   4   5   6   >