Daniel Phillips wrote:
> Curtis Anderson wrote:
> > For example, "mv" will devolve to "cp" when the source and destination
> > filesystems are different.  So "mv" will preserve attributes for some
> > operations, and will drop them on the floor for others.  Unexpected by the
> > average user, and therefore bad.
> 
> But why should cp drop attributes?  I can see cat foo >bar dropping
> attributes, but not cp.

If it were updated to support EA's, it would not drop them.  It is an
example of a program that makes assumptions about the "shape" of a file
(ie: not having EA's), and that would need to be modified.  I don't know
of a way to get the attribute copying to happen automagically, especially
given that sometimes you want them copied and sometimes not, so I believe
that the utility's code needs to be modified.

It was given as an example in support of my assertion that adding EA's
in a consistent fashion to an OS is not a trivial task.  In order for
users to not get surprises when they sometimes go away, all of the tools
in the system need to be examined and possibly updated.  The scale of the
problem is what makes it a problem, not the task of updating any single
utility.


Daniel Phillips wrote:
> Curtis Anderson wrote:
> > It's an aesthetics argument.  There are no new features in a directory-based
> > streams-style attribute mechanism over basic filesystem semantics.  It would
> > be bad to confuse things by trying to say that this is "new" or "different"
> > when it is not.
> > [snip]
> > The problem with streams-style attributes comes from stepping onto the
> > slippery slope of trying to put too much generality into it.  I chose the
> > block-access style of API so that there would be no temptation to start
> > down that slope.
> 
> Could you please produce a more substantive argument. :-)  You are
> making an excellent argument in favor of doing exactly what you seem to
> oppose.

I think it comes back to the aesthetics of it.  I don't like the idea
of taking something we have now and that we all understand and trying
to put a new name on it and pretend it is new.  I'm looking for things
that have new semantics or new access methods, things that may spark
new ways of doing things.

Thanks,

        Curtis
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]

Reply via email to