Alexander Larsson wrote:
On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote:
Should sed -i use fsync()? If it
is promising atomic-change-in-place, then it certainly should.
This is the same kind of reasoning that says its ok to do something
because its specified by posix. If its not defined somewhere that sed -i
must use fsync, is it then ok to lose users data. Its certainly per the
spec, but its a pretty sucky system that I wouldn't want to use.
If sed -i does NOT make strong promises about your data, and you trust
sed -i with your data, then the person who lost the data is you, for
choosing to use sed -i and trusting it with your data.
If sed -i DOES make strong promises about your data, then it should
absolutely use fsync() to explicitly confirm that the data is safe
before doing the rename().
Blaming it on the file system for not guessing your intent is
unreasonable. If you truly have such expectations, make sure that all of
your mounts are synchronous and that you only use fully journalled file
systems. You will probably have to reduce your expectations about
overall system performance as a result.
Personally, I've ALWAYS been wary of perl -i (same thing as sed -i). I
have never read anywhere that it guarantees the safety of my data. I
always do backup of the files before I start, and carefully check the
results after I finish. But, that's me...
Cheers,
mark
--
Mark Mielke <[email protected]>
_______________________________________________
gtk-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
