Message219273
So, maybe API change? like delete=True|False|Maybe ? don't think that this is good decisions.
My approach is based on ext4 behaviour about delayed allocation and atomic file replacements.
In my case, either old file (with contents) or new file appear.
In any case, corrupted data cannot appear.
This is required behaviour for my application.
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
http://lwn.net/Articles/322823/
=======================================================================
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
=======================================================================
So, this is essential functionality. |
|
Date |
User |
Action |
Args |
2014-05-28 15:12:49 | socketpair | set | recipients:
+ socketpair, georg.brandl, ncoghlan, pitrou, vstinner, berker.peksag, serhiy.storchaka |
2014-05-28 15:12:49 | socketpair | set | messageid: <1401289969.55.0.182335182153.issue21579@psf.upfronthosting.co.za> |
2014-05-28 15:12:49 | socketpair | link | issue21579 messages |
2014-05-28 15:12:46 | socketpair | create | |
|