Hi Ethan,
> On Tue, Jun 11, 2002 at 12:22:07PM +0200, Matteo Centonza wrote:
> >
> > are you sure you have mastered all details?
>
> unless something changed very recently yes.
no, reasons still apply ;)
>
> > Using a reserved namespace, means ``Hey, this is administrator things'',
> > so it's up to the administrator to set this kind of stuff, not to the
> > user. With this approach, you're on the safe side IMHO. BTW, if the
> > administrator smokes Crack then you're toast anyway ;)
>
> there is no such namespace at this time. system.* is special, there
> are only specific system namespaces defined and the user (even root)
> cannot just make up new ones. right now there is
> system.posix_acl_access (only file owner may write this attribute) and
> system.posix_acl_default (same as _access). there is also an xfs
> specific system.xfsroot (i think thats right) which only root may
> read/write/see. the only other xattr namespace at the moment is
> user.* which is entirely controled by the file/dirs permission
> bits. (with exceptions for symlinks and special files).
are system.xfsroot (like, if any) feasible for this?
> there has been discussion about making a owner.* namespace or such,
> which would only be writable by the file owner, but this does not
> exist as of yet.
>
> so you see there is no place for this per directory attribute except
> perhaps the system.xfsroot namespace, but im not entirely sure this
> namespace is really meant to be fscked with by end users.
>
> > As you stated above ext* already have a similar feature.
>
> ext2 allows the object *owner* to decide this, Ivan is of the opinion
> that the file owner shouldn't have that authority in the case of a
> directory, thats debatable. if we are discussing implementing the
> ext2 feature as it works now there is NOT sufficient infrastructure in
> the extended attributes to do it. (there is no xattr namespace that
> allows arbitrary attributes which are only writable by the file owner).
Yet again, you have to consider this as an administator feature,
not an user one. Doing so, you can skip a lot of implementation
complexity.
>
> i am of the opinion that if only root is to be allowed to exclude
> directories then it should be done with an xfsdump command line
> argument and not a filesystem attribute. i tend to agree with ivan
> that allowing lusers to arbitrarly exclude directories from backups is
> probably not a good idea. (fwiw all i use the ext2 chattr +d for is
> crap like browser cache and large source trees i only plan to keep
> temporarly and don't want my limited backup space exhausted by).
well, i disagree here. If you use to wrap around your dump command with a
backup suite like AMANDA (that ``silently ignores exclude list by dump'')
you cannot reach the same goal easily. In any case, doing so you have a
lot more low level control on your backup process, transparently to the
end application. Imagine you have to dynamically add via an application a
new dir that won't be backed up to your filesystem. Immediately you
have to extend the list of backed-up trees in your dump command ;(
Just thoughts,
-m
|