extended attributes

[James Wilkinson]

Russell Strong wrote:
> I tried editing a file where I didn't have write permission on the directory, 
> only have write permission on the file.  That worked as I expected, the EAs 
> were preserved and the inode did not change.  Anyone know why vim behaves 
> differently when it has write permissions for the directory?  Is this a vim 
> "bug" ( not behaving the way ?most? users expect ) or is there a reason?

Oh yes, there certainly is a reason....

As I understand it, the normal way that vim saves a file is to create a
new file, give it the appropriate ownership and permissions (and these
days SELinux attributes), write everything into that file, and rename it
to the desired filename.

This means that if the program (or system) crashes for any reason while
it's writing the file, at least the old version of the file is still
there. If you're editing something in /etc, this might be a Very Good
Thing. It means that writing changes is pretty well transactional --
either all the changes are applied, or none are.

But if the user can't write to the directory, then vim can't create that
new file (or delete the old one). So it *has* to work with the existing
file, in place. So of course the EAs stay put.

There are times when this behaviour is very useful. For example, if you
want a number of kernel source trees on disk, you can use cp -rl to
"copy" one tree to another. But the actual source files are only stored
on disk once: each file just appears twice, once in each tree ("it has
multiple links"). So you don't need double the disk space.

The patch utility works the same way as vim: you can then apply a patch
to update one tree (say from 2.6.15 to 2.6.16). When it changes a file,
it will create a new copy of the file on disk, and delete *one* link to
the old file. But the link in the other tree is still there. So the
unaltered copy of the file remains on disk, and is accessible through
the old tree. The altered copy is also on disk, and only accessible
through the new tree.

So you only need the disk space for one kernel tree plus the files that
have been changed.

In the same way, you can take a cp -rl copy of a kernel tree, make a
number of edits with vim, and have a logically completely separate
kernel tree (so you can compile it), but which only takes up the size of
the files you've changed.

Hope this helps,

James.
-- 
E-mail address: james | Space Opera: General term for a subgenre of adventure
@westexe.demon.co.uk  | SF in which the men are heroic, the women beautiful,
                      | the monsters monstrous, and the spaceships make
                      | whooshing sounds in hard vacuum. -- Eric Raymond