On September 6, 2012 at 7:23 PM Paul Eggert <egg...@cs.ucla.edu> wrote:
> On 09/06/2012 10:12 AM, Bob Proulx wrote: > > The file replacement is atomic. The reading of the file is not. > > Sure, but the point is that from the end user's > point of view, 'sed -i' is not atomic, and can't > be expected to be atomic. > > 'sed -i' and 'sort -o' both use some atomic operations > internally, but neither is atomic overall. Users who > want atomicity must look elsewhere, or implement it > themselves. Why can't 'sed -i' be made atomic for the user? Today, it creates a temporary file for the output. At the end, it calls rename(). What if it instead rewinds the input and that temporary file and copies it's content to the input file? Okay, this is slower than a rename(), but it would write into the same inode. To preserve today's behaviour, this could be done with a new option like --in-place-same. Just a thought. Have a nice day, Berny
