Re: extended attributes

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

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: Did the Trojan war really happen the way Homer said it did?
    ... Evans 13, Ohlenroth I, shows a tree and refers to itea ... The same tree signs appear on the gold signet ... Phaistos Disk, they are even slightly smaller than on the disk: ... sacrificed by the king of Tiryns or one of his four ministers ...
    (sci.archaeology)
  • Re: Did the Trojan war really happen the way Homer said it did?
    ... Evans 13, Ohlenroth I, shows a tree and refers to itea ... The same tree signs appear on the gold signet ... Phaistos Disk, they are even slightly smaller than on the disk: ... sacrificed by the king of Tiryns or one of his four ministers ...
    (sci.lang)
  • Re: Linux 2.6.16.58
    ... also present in my local tree, I'm certain that it remained there ... branch of his mips tree, so it must have been somehow possible... ... So it was somehow possible to get it through the anonymous git server, ... "One disk to rule them all, ...
    (Linux-Kernel)
  • Re: Thinking outside the box on file systems
    ... have to consider just the in-memory dentries, but *all* the descendent objects ... are only computed in memory when the dentry for a child is created, so you don't have to do a bunch of disk churning to change permissions on the whole tree. ... The whole idea here is that there is ONE acl that applies to the whole tree, rather than have every object in the tree have its own acl. ...
    (Linux-Kernel)
  • Re: Strange linux-next build error
    ... the bug triggers. ... of the tree and started the build. ... permissions, the correct ownerand all that - so I didn't look deeper. ...
    (Linux-Kernel)
Loading