New submission from Thomas Waldmann :
See there:
https://github.com/borgbackup/borg/pull/4247
I did the first changeset after seeing some strange exception popping up which
it was handling another exception - which I assumed was related to
memoryview.release not being called in the original
Thomas Waldmann added the comment:
working, but potentially problematic because .release is not always called
(e.g. in case of an exception).
--
Added file: https://bugs.python.org/file48031/issue35686a.py
___
Python tracker
<ht
Thomas Waldmann added the comment:
with context manager, does not work.
--
Added file: https://bugs.python.org/file48032/issue35686b.py
___
Python tracker
<https://bugs.python.org/issue35
Thomas Waldmann added the comment:
with try/finally: works.
--
Added file: https://bugs.python.org/file48033/issue35686c.py
___
Python tracker
<https://bugs.python.org/issue35
Thomas Waldmann added the comment:
hmm, issue tracker does not make it easy to see which file was uploaded for
which comment, so:
a: original code, works, potentially problematic exception handling (memoryview
not always being released)
b: using the memoryview context manager, fails with
Thomas Waldmann added the comment:
I see 2 issues here:
1. I would expect that the CM approach (b) behaves equivalent to try/finally
(c), but it does not and even causes an exception.
2. The traceback given in the BufferError (in (b)) is misleading, it points to
the "print",
Thomas Waldmann added the comment:
https://github.com/borgbackup/borg/pull/4247/files
this is the current code i have for this (it is not as simple there as in the
minimal code samples i attached here).
i meanwhile think i can not use a contextmanager there.
do you think this is as good as
Thomas Waldmann added the comment:
Embarassing as always to stumble over some stuff and then find a 9y old ticket
here, where it is discussed and even (almost) solved.
Our ticket: https://github.com/borgbackup/borg/issues/3471
Fixed getfqdn we use now instead of socket.getfqdn():
https
New submission from Thomas Waldmann :
When running the borgbackup tests on 3.7.0, quite some tests will be broken
because expected log output is not emitted.
I traced this down up the point when I noticed that reverting the caching
feature change of isEnabledFor method in Logger makes the
Change by Thomas Waldmann :
--
components: +Library (Lib)
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue34269>
___
___
Python-bugs-lis
Thomas Waldmann added the comment:
https://github.com/borgbackup/borg/pull/3998
Looks like this fix to our test tearDown method makes the tests work again.
If one looks at what this dirty/problematic hack was done, it might be because
of a missing logging reset functionality
Thomas Waldmann added the comment:
I agree that we should not dig that deep into logging internals and clear that
dict from borg code.
But, seems like one has no public api to reinitialize logging to a like-fresh
state, right? So maybe THAT is the real problem.
Add some .reset() method to
Thomas Waldmann added the comment:
Well, if you have a better idea how to fix is_zipfile, go on.
I even suggested an alternative, how about that?
It is a miserable state when the is_zipfile function in the stdlib detects
random crap as a zip file
Thomas Waldmann added the comment:
gave 2.7.4rc1 a try and was seeing a failing unit test that does not fail with
2.7.3.
see the attached file for some minimal code that succeeds on 2.7.3, but not on
2.7.4rc1.
it seems to have to do with being a subclass of Exception, it doesn't happen
New submission from Thomas Waldmann:
platform.libc_ver() is trivially broken as it uses string comparison internally
to determine the maximum libc version number (which is obviously broken as
"2.9" > "2.10").
--
components: Library (Lib)
messages: 261624
nosy: T
New submission from Thomas Waldmann:
os.walk calls itself recursively and that limits the directory depth it can
"walk" into.
On Linux, one can create directory hierarchies deeper than that.
For some more details see there:
https://github.com/borgbackup/borg/issues/380
--
Thomas Waldmann added the comment:
Note: similar issues can be seen in other stdlib recursive filesystem-related
functions also.
--
___
Python tracker
<http://bugs.python.org/issue26
New submission from Thomas Waldmann:
zipfile.is_zipfile has false positives way too easily.
I just have seen it in practive when a MoinMoin wiki site with a lot of pdf
attachments crashed with 500. This was caused by a valid PDF that just happened
to contain PK\005\006 somewhere in the middle
Thomas Waldmann added the comment:
patch for py2.7
The EOCD structure is at EOF.
It either does not contain a comment (this is what the existing code checks
first) or it contains a comment of the length that is specified in the
structure.
The patch checks consistency specified length vs
Thomas Waldmann added the comment:
Note: checking the first bytes of the file (PK..) might be another option.
But this has the "problem" that a self-extracting zip starts with an executable
that has different first bytes.
So whether this is an option or not depends on whether
20 matches
Mail list logo
