Ted Ts'o <tytso <at> mit.edu> writes: > 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.
IMO calling a recipe containing fsync() "the right answer" is wrong. For the clear majority of programs waiting for a disk-level write is not the correct semantics, and using fsync does cause real problems, the recent dpkg issues here being just one example. IMO telling people to use fsync does more harm than good; rather we should be telling them to not use fsync unless they really know what they're doing. In another post in this thread you also talk about how we've managed to live with the current functionality for three decades. We've managed to live, but what exactly is the practice we've lived with? I'd say an essential part of it has been the recipe of "write temp file + rename", _without_ doing an fsync. Yes, it may not have been theoretically crash safe on all filesystems; but in practice, the practice that has allowed things to work for decades, the filesystems have either been safe or the machines stable enough for it to not become an issue. If this is no longer true then that is a reason why things are now different from previous decades and why it's now necessary to add new functionality. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110103t195257-...@post.gmane.org
