Re: [PATCH 1/2] report: safely update the result.xml file

["Theodore Ts'o" <tytso@mit.edu>]

On Sat, Jul 08, 2023 at 12:17:47AM +0800, Zorro Lang wrote:
> > sync "$tmp_fn" && mv "$tmp_fn" "$out_fn"
> 
> I can help to add this when I merge it, if Ted doesn't want to change
> more than that.

I'll be sending out v2 shortly.

> Just curious, will renameat2 ignore data still in cached? I never did things
> likes "sync && mv" before, is there any known issue or it's as expected?

POSIX does not require rename() or renameat2() to do anything with any
cached data.  All it does is make changes to the directory entries
involved.   And that's what the VFS Layer does.

Some file systems implementation *may* do something special on a
rename(2), but it's not required by any specification.  For example,
in the wake of the O_PONIES controversy, ext4 will initiate (but not
wait for) the file writeback of file being renamed *if* it is being
renamed on top of another file, causing the destination inode to be
unlinked and deleted if it doesn't have any other hard links to keep
its reflink about 0.

This means that in the case of renaming result.xml.new on top of
result.xml, if result.xml exists, this will trigger an immediate
writeback of result.xml.new, instead of waiting for the 30 second
writeback timer --- if this is happening on ext4.  We added this to
ext4 because when people would exit the old Tuxracer game, this would
rewrite the top ten file in an unsafe manner, and then close the
OpenGL handle --- and on kernels with buggy proprietary graphics
drivers, it would cause a kernel crash, causing the top-ten score file
to be lost, and causing many users to complain to the file system
developers (but curiously enough, not to the application/game
developers).  So we added something which reduces the chances of this
being an issue, but it's not something anyone should count upon.

As far as sync && mv, that's the shell script equivalent of what
careful userspace programs should always do, which is to write the
file to foo.new, then fsync it, and then rename foo.new to foo,
optionally renaming foo to foo.old or foo~ beforehand.  Text editors
have always gotten this right, because programmers get salty when
their source files get trashed.  For whatever reason, desktop
application and games tend not be as careful....

Cheers,

						- Ted