[Top] [All Lists]

Re: Anyone using XFS ACLs? (fwd)

To: Danny Cox <danscox@xxxxxxxxxxxxxx>
Subject: Re: Anyone using XFS ACLs? (fwd)
From: "Nathan Scott" <nathans@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 23 Jul 2001 17:43:02 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Steve Lord <lord@sgi.com> "Re: Anyone using XFS ACLs? (fwd)" (Jul 20, 1:33pm)
References: <200107201833.f6KIX7H08390@jen.americas.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
hi Danny,

On Jul 20,  1:33pm, Steve Lord wrote:
> Subject: Re: Anyone using XFS ACLs? (fwd)
> This was sent privately, Danny later said he meant to send to the list,
> any message mangling is entirely the fault of my mail tool. I expect we
> will get something based on this into the tree fairly soon (is anyone
> in Australia listening? hint hint).
> Steve
> ------- Forwarded Message
> Date:    Fri, 20 Jul 2001 12:35:35 -0400
> From:    Danny Cox <danscox@xxxxxxxxxxxxxx>
> To:      Steve Lord <lord@xxxxxxx>
> Subject: Re: Anyone using XFS ACLs?
> This is a multi-part message in MIME format.
> - --------------4E072E6D209773EBBDAD1589
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Steve,
> Steve Lord wrote:
> > The other option here is for someone to take the source of something
> > like chown which has a -R option, and chacl which does not. Merge the
> > two and send in a patch. This is the sort of project which would be
> > fairly easy for someone to tackle, would solve a problem. We are
> > very tight on resources here and cannot be relied upon for things
> > like bells and whistle extensions to commands like this.
>       Steve, here is a patch that adds an '-r' arg to chacl, and decends
> (depth first) a directory tree changing ACLs as it goes.  It doesn't
> attempt to list them recursively, as that is a little trickier (and
> neither chown nor chmod attempt this).
>       I did have a little problem.  The "Makefile" uses the
> '-D_FILE_OFFSET_BITS=64' which comes from ../include/builddefs, which
> comes from ../include/builddefs.in, and causes the readdir to not work
> correctly.  The included file "<dirents.h>" gets the wrong size, which
> doesn't agree with my libc (I'm using RedHat 6.2, and it's standard
> glibc).  When I recompiled without that flag, it works like a champ.
>       Short of defining 'struct dirent' myself (HACK!), I don't know how to
> work around this other than how I did (remove the flag, which probably
> breaks something else).

Tim and I were just having a look through this & we have a
couple of questions/observations:

- the descent algorithm you've used seems to be breadth-first,
rather than depth-first ... was this your intention?  (your
mail suggests not).  We agree it should be depth first (easily
fixed by moving the call to walk_dir up to the top of set_acl);

- trying to understand your '-D_FILE_OFFSET_BITS=64' problem -
I think we do need this, I just can't understand how this was
failing for you (can you give more details?) - I have a rh6.2
system here and it seems to work for the (limited) test cases
we tried.

We looked through the fileutils-4.1 code and that seems to
define _FILE_OFFSET_BITS to 64 (via config.h) on redhat 6.2

Otherwise, the patch looks fine - I'll probably check it in



<Prev in Thread] Current Thread [Next in Thread>