Re: mv should call fsync before erasing source file

[Jim Meyering]

drwowe wrote:
> I was moving some files with mv from a hard drive to a flash drive.  The
> flash drive is very slow.  The mv command finished and the original files
> were gone but I realized the operating system still had a gigabyte or so of
> data in RAM which was in the process of being written to the flash disk.  I
> ran "sync" to make sure everything was flushed and it took almost 60 seconds
> to finish writing.  If my computer had crashed during that minute, the data
> would have been gone.
> Either by default, or at least with a command line flag, mv should call
> fsync() on the new file being written and wait for a successful return
> before erasing the original file.  Otherwise there is a significant window
> of opportunity for significant data loss.  In theory, that window is
> infinite according to POSIX standards, in practice my example shows that it
> can be on the order of minutes which is just too long in my opinion to leave
> a user's data in jeopardy.

Maybe you want a new option to enable this behavior when
mv does not do an atomic rename, but it will never be the
default, because it would cause a huge performance hit
when copying many files between devices.

However, in the meantime, I suggest you use a different
approach, like copy-to-removable, unmount-removable, remount
removable, compare, and *then* remove the original.

If you're in a hurry, dd's oflag=direct (aka O_DIRECT)
should be good enough to do the copy.  When it completes,
you can safely remove the original.