On Fri, Jul 07, 2023 at 03:13:31PM -0400, Theodore Ts'o wrote: > 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.... Thanks Ted, good to know that! Maybe we can have a "_mv" in common/rc does "sync $1 && mv $1 $2". Thanks, Zorro > > Cheers, > > - Ted >
