From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10107231743.ZM221213@wobbly.melbourne.sgi.com>
Date: Mon, 23 Jul 2001 17:43:02 +1000
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>
To: Danny Cox <danscox@mindspring.com>
Subject: Re: Anyone using XFS ACLs? (fwd)
Cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

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@mindspring.com>
> To:      Steve Lord <lord@sgi.com>
> 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
also...

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

thanks.

-- 
Nathan