Re: [Gnu-arch-users] Re: give us a hand with arch

[Ethan Benson]

On Sun, Sep 28, 2003 at 10:35:57PM +0200, Harald Meland wrote:
> [Ethan Benson]
> 
> > On Sun, Sep 28, 2003 at 12:59:51AM +0200, Harald Meland wrote:
> >> For example, on this Debian box Emacs is by default set up to create
> >> backup files by renaming.  While I'm not claiming to have looked very
> >> closely at xattr semantics, I would guess that
> >> 
> >>   rename(file, file~)
> >>   open(file)
> >>   ... write new contents ...
> >>   close(file)
> >> 
> >> would leave the user with the original file-id xattr in file~ (which
> >> by default would be ignored by tla), and no corresponding xattr in
> >> file.  This would be bad.
> >
> > no, rename() supports xattr.
> 
> Uhm, yes.  But does open(2) automatically add the same xattrs to the
> file it just created?  I think (and certainly hope ;-) not.

no. of course not. why would it? where would open(2) even see such an
xattr? the parent directory?

> (BTW: This argument applies equally well to Andrea's "separate
> meta-data stream in the inode" mirage.  Such a feature would, for the
> very same reasons outlined in my pseudo-code example above, require
> changes to (lots of) tools before things start working the way he
> claims they will.)

yes this is true.  IMO xattrs are a useful thing since they are
limited to a small ammount of data, and primarly are used for
extending the filesystem (adding ACL support for example) rather then
to store user data, though the latter is possible.  often times user
xattrs are not something you would want to be preserved outside of
your local machine anyway.

resource forks on the other hand are used primarily to store user
data, therefore you end up with data loss as a fact of life, xattrs
don't allow enough data to where you could be terribly upset if they
are lost.  this is why i feel resource forks are a BAD idea and should
not be implemented.  (and in fact apple has come to this realization
as they have deprecated the use of resource forks in OSX).

> > however file copying requires xattr support.
> 
> Ahh, good, my hope was justified. :-)

patched cp(1) for example will only preserve an xattr if you tell it
to, just as it doesn't preserve permissions unless you tell it to.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

pgp7DmeAyMNeN.pgp
Description: PGP signature