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
