Comment 27 for bug 817326

> After powering up, the GEdit document is intact and contains the latest
> content, whereas the LibreOffice document is gone forever.

Thanks for testing. This is as expected, unless we use 'rename' - and the code needs fixing to do that. *Unfortunately* the code is far worse than a rats nest here.

Using 'rename' seems like an easy & trivial thing to do right ? it is the elegant solution to avoiding 'fsync' - but this is not really so. It is fairly easy to create a file-system for which we have no ability to create files in the same directory that can be renamed over the top - and finding other directories on similar file-systems for which 'rename' can validly replace a file in another directory is a twisted mess of nastiness. In these cases we -have- to open that file, write stuff to it - and then we can't call fsync because it is a "bust your system interactivity, break your burning DVD, jitter your sound playback, and make people think LibreOffice kills babies" syscall on old file-systems, where 'old' means 'widely deployed' :-)

Worse - there is no standard library out there that wraps 'fsync' into a 'sane_fsync' that will tell us what file-systems underlies the file, and ensure that we are only calling fsync where it is safe (cf. above). If some enterprising kernel hacker wants to create a nice, ultra-liberally licensed library that turns a dev_t into a boolean: int is_it_safe_to_fsync (dev_t *t); then I'd be more than happy to see it used un-conditionally in our system-abstraction for Unix / Linux. Which would prolly solve the problem. AFAICS dev_t's are pretty useless; perhaps we'd need to parse /proc/mounts and combine that with the horrible stat walk we already do to determine file-system type, and then start doing string munging: "ext4" - safe to 'fsync', "btrfs" - prolly a good idea to 'fsync' - or is it ? perhaps only > some version of btrfs, and for ext3/ext2 etc. there is no need - they tend not to wantonly loose your data ;-)