[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Safe File Update (atomic)

On Mon, Jan 3, 2011 at 3:43 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Mon, Jan 03, 2011 at 12:26:29PM +0100, Olaf van der Spek wrote:
>> Given that the issue has come up before so often, I expected there to
>> be a FAQ about it.
> Your asking the question over (and over... and over...)  doesn't make
> it an FAQ.  :-)

Haha, right. But file loss issues have come up before. Let's wait for
the userspace lib.

> Aside from your asking over and over, it hasn't come up that often,
> actually.  The right answer has been known for decades, and it's is
> very simple; write a temp file, copy over the xattr's and ACL's if you
> care (in many cases, such as an application's private state files, it
> won't care, so it can skip this step --- it's only the more generic
> file editors that would need to worry about such things --- but when's
> the last time anyone has really worried about xattr's on a .c file?),
> fsync(), and rename().

> This is *not* hard.   People who get it wrong are just being lazy.

True, that's why right/safe-by-default would be nice to have.

> In the special case of dpkg, where they are writing a moderate number
> of large files, and they care about syncing the files without causing
> journal commits, the use of sync_file_range() on the files followed by
> a series of fdatasync() calls has solved their issues as far as I know.


Reply to: