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

On Thu, 28 Aug 2003 06:24:03 +0200, "Philipp Thomas" said:

...

So in linux there is no way to have some files in "a" directory that are writable and some files that are not? Directly, no. But with a trick it's possible. Create the files in a

Mark Hounschell [Wed, 27 Aug 2003 16:26:50 -0400]: directory that is owned by root and symlink them into the directory where the user has write permissions.

Check this out: # cd /tmp # mkdir xx # chmod g+w,o+t xx # sudo chown root xx # ll -d xx drwxrwxr-t 2 root users 35 Aug 27 23:24 xx # cd xx # touch yy # sudo touch zz # ll total 0 -rw-r--r-- 1 msiefrit users 0 Aug 27 23:24 yy -rw-r--r-- 1 root root 0 Aug 27 23:24 zz # rm yy # rm zz rm: remove write-protected file `zz'? y rm: cannot unlink `zz': Operation not permitted #

From the ulink man page:

EPERM or EACCES The directory containing pathname has the sticky- bit (S_ISVTX) set and the process's effective uid is neither the uid of the file to be deleted nor that of the directory containing it. So with the sticky bit (t) set you need to own the file or the directory to be able to delete the file. HTH Michael