Re: Safe File Update (atomic)
On Mon, Jan 3, 2011 at 3:43 PM, Ted Ts'o <firstname.lastname@example.org> 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.