mv question

[Tonatiuh]

Red Hat Enterprise Linux AS 4

What happen if I try to move ( with command "mv") a file that is being written exactly at same time I am trying to move it?

1) Does it result corrupted?
2) Does the moved file is not complete (the rest of the written file remains in the original location?
3) Does the commmand wait until that process that is writing to the file terminates and after that, the command moves the file?

Same questions for "cp" command?

[Ivan Ferreira]

Using simple test is possible to see:

You can move a file while is generated/populated, the file generation process will continue and the data will be available at the new location, without any corruption. The file will be moved immediatly while is generated/populated.


You can copy a file while is generated/populated, but the copy process will hang waiting for the file to be complete before copying all the contents of the file. The files will have the same data and there will be NO data loss.

[Alexander Chuzhoy]

The thing is that you don't edit the file but it's copy.
Usually, if the filename was test, then the name of the copy on which the system will work will be .test.swp

So there's no problem of copying /moving the file while editing.

[Mike Stroyan]

The behavior actually depends on where you move a file from and to.

If you mv a file within a single file system, then the mv command does a rename(oldpath,newpath). That means that the file keeps the same inode. Processes writing to the file won't see any disruption. All writes will end up in the file at its final name.

If you mv a file from one file system mount point to another, then the mv command must copy the file be reading from the first location and writing to the new location. When the last data is read and written the old file location is removed with a call unlink(). Other processes that are writing to the file will continue to have the open file descriptors for the original inode as long as they hold them open. But further writes will not appear in the new file location. They will be available for reads by processes that are keeping open file descriptors for the original file. (If the original file had multiple hard links then you could still see the full effect of those writes through opening one of the other hard links.)

[Mike Stroyan]

I should also point out that if the original file had only one hard link and was "mv"d to a different file system, then the original file will eventually go away when the last open file descriptor for the file is closed. That delay to release a file is a common source of confusion for system administrators who remove a big log file. The link count reaches zero, but the unseen file continues to take up disk space until all processes writing to a log file actually close there open file descriptors for it.