Paul Varner wrote:
If you own the directory and have read/write permission then things like this can happen. What is happening is that vim is trying to be helpful and do what you told it to do. Since you gave it a w! command, it takes that to mean "I really really want to write this file" and what vim did was delete the original using the unlink system call, created a new file with the same name using the open system call, wrote its buffers to the new file and when you quit it closed the file. Since the read/write directory permissions allow you to remove and create files, vim successfully wrote the file.
Not all editors will exhibit same behavior. I know that on a Solaris box, the vi command will not write a file if you don't have write permissions on the file.
Quite correct. Just did the procedure, with strace running on vi(m), and sure enough it tries to open the file for writing, fails, deletes the file, opens for writing again and writes out the contents. Earlier in the thread someone mentioned checking the inode number, and on my first run through I did that and Hey Presto! the inode number was the same. I was starting to get paranoid that the file was being written and chowned/chgrped! Then I realised, that on a desktop machine, with not a great deal of activity in /home at the time, then deleting a file, followed the creation of another immediately afterwards will most likely end up getting the recently freed inode number. You can force a different inode number for the new file, by deleting some other files on the same file system immediately prior to doing the write in vi(m). Cheers, -Bruce