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.
