This is something that can happen with filesystems when you have write access to the file but not to the directory. When you are overwriting files, there are multiple strategies that can be followed:
- delete the old file and write the new one. This fails if you do not have delete permission for the file, or if you do not have create permission in the directory. If something happens between the time of the delete and the time the new file is created, you can be left with no file at all. If something happens after the new file is created but before it is finished being written , you can end up with a partial file
- rename the old file and write a new one, and if failure, attempt to rename the old file back. Renaming the old file can fail if you do not have write permission in the directory, leading you not to write into a place you have access -- but at least in this case you do not lose anything. If there is a problem with the writing of the new file, it is possible that whatever the issue is will prevent you from renaming the old file back again. The new file might not be able to get the same permissions and ownership as the old file.
- write the new file into a temporary file on the destination file system, and when writing works successfully, rename the temporary to the name. This can fail if you do not have write permission to the directory. Glitches can lead to the temporary file being left in place. The new file might not be able to get the same permissions and ownership as the old file
- write the new file directly on top of the old file. Permissions and ownership are certain to be preserved. Failure during the write process can leave you will a corrupt file and no way to get back.
Different programs can choose different ones of these, with different potential consequences.
Remote filesystems find it more difficult to meet atomicity guarantees, so using a temporary file becomes more common -- but that introduces the kinds of permission problems that I discussed earlier.
It is also not rare to have a failure writing to a remote file, especially if the program doing the writing is doing a number of ioctl's or a number of fseek (such as might be needed to update an index at a fixed position in a file.)
It is typically faster and more robust to write to a local disk and then copy the local file to the remote system.