[issue28847] dumbdbm should not commit if in read mode

Changes by Donald Stufft : -- pull_requests: +962 ___ Python tracker ___ ___

[issue28847] dumbdbm should not commit if in read mode

Roundup Robot added the comment: New changeset 0a74bc7ba462 by Serhiy Storchaka in branch '3.5': Issue #28847: dbm.dumb now supports reading read-only files and no longer https://hg.python.org/cpython/rev/0a74bc7ba462 New changeset 0c532bd28539 by Serhiy Storchaka in branch '3.6': Issue #28847:

[issue28847] dumbdbm should not commit if in read mode

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

Serhiy Storchaka added the comment: Thanks Martin for pointing on this. Now buildbots are green. -- ___ Python tracker ___

[issue28847] dumbdbm should not commit if in read mode

Roundup Robot added the comment: New changeset cb4a892e9b66 by Serhiy Storchaka in branch '2.7': Try to fix test.test_support.rmtree() on Windows for fixing issue28847 tests. https://hg.python.org/cpython/rev/cb4a892e9b66 -- ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

Martin Panter added the comment: http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/9/steps/test/logs/stdio == ERROR: test_readonly_files (test.test_dumbdbm.DumbDBMTestCase)

[issue28847] dumbdbm should not commit if in read mode

Roundup Robot added the comment: New changeset dc7c86de9e13 by Martin Panter in branch '2.7': Issue #28847: Fix spelling https://hg.python.org/cpython/rev/dc7c86de9e13 -- ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

Martin Panter added the comment: Serhiy: The Windows buildbots are having trouble removing read-only files. Maybe restore the write mode for the end of the test, or fix support.rmtree()? See . -- nosy: +martin.panter

[issue28847] dumbdbm should not commit if in read mode

Serhiy Storchaka added the comment: The first part is committed in 2.7. I'll commit it in 3.5-3.7 after releasing 3.6.0. -- versions: -Python 2.7 ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

Roundup Robot added the comment: New changeset 0516f54491cb by Serhiy Storchaka in branch '2.7': Issue #28847: dubmdbm no longer writes the index file in when it is not https://hg.python.org/cpython/rev/0516f54491cb -- nosy: +python-dev ___ Python

[issue28847] dumbdbm should not commit if in read mode

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka versions: +Python 2.7, Python 3.5, Python 3.6 ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

Jonathan Ng added the comment: #1 makes sense to be backported. On Thu, Dec 1, 2016 at 8:41 PM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > This example is too artificial. > > But there is a real issue: opening read-only files in read mode.

[issue28847] dumbdbm should not commit if in read mode

Serhiy Storchaka added the comment: This example is too artificial. But there is a real issue: opening read-only files in read mode. Currently this causes a PermissionError on closing. For backward compatibility flags 'r' and 'w' are ignored. I.e. opening with 'r' and 'w' creates a file if

[issue28847] dumbdbm should not commit if in read mode

Jonathan Ng added the comment: I'm not sure how to create an OSError. But perhaps something like this: ''' from dbm import dumb import os db = dumb.open('temp', flag='n') db['foo'] = 'bar' db.close() db = dumb.open('temp', flag='r') print(len(db.keys())) db.close os.rename('temp.dir',

[issue28847] dumbdbm should not commit if in read mode

Serhiy Storchaka added the comment: Do you have concrete example when not ignoring an OSError in _update causes an issue? This is needed for writing tests. -- components: +Library (Lib) nosy: +serhiy.storchaka ___ Python tracker

[issue28847] dumbdbm should not commit if in read mode

New submission from Jonathan Ng: Or at the very least, if there is an OSError in _update, an error should be raised instead of ignoring this error. In the current state of the code, if there was an OSError while reading the dirfile, the dirfile would be overwritten with a blank file when it