This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author socketpair
Recipients berker.peksag, georg.brandl, ncoghlan, pitrou, serhiy.storchaka, socketpair, vstinner
Date 2014-05-28.15:12:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.

auto_da_alloc(*)	Many broken applications don't use fsync() when 
noauto_da_alloc		replacing existing files via patterns such as
			fd = open("")/write(fd,..)/close(fd)/
			rename("", "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:49socketpairsetrecipients: + socketpair, georg.brandl, ncoghlan, pitrou, vstinner, berker.peksag, serhiy.storchaka
2014-05-28 15:12:49socketpairsetmessageid: <>
2014-05-28 15:12:49socketpairlinkissue21579 messages
2014-05-28 15:12:46socketpaircreate