xfs
[Top] [All Lists]

Re: Bug#499076: Physical walk no longer ignores all symlinks

To: tes@xxxxxxx
Subject: Re: Bug#499076: Physical walk no longer ignores all symlinks
From: Nathan Scott <nscott@xxxxxxxxxx>
Date: Tue, 16 Sep 2008 11:07:31 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1221526247.21658.21.camel@xxxxxxxxxxxxxxxxxx>
References: <1221526247.21658.21.camel@xxxxxxxxxxxxxxxxxx>
FYI... that last acl/attr attempt to address symlinks has
broken things for some people it seems ... any thoughts on
the options Kevin lists at the end?

thanks.

On Tue, 2008-09-16 at 10:20 +0930, Kevin Shanahan wrote:
> Package: acl
> Version: 2.2.47-2
> 
> After upgrading a system from Etch to Lenny, we are having some problems
> with our backup scripts which rely on getfacl/getfattr.
> 
> Previously we had been using "getfacl -RP ..." to recursively dump all
> the ACLs in a number of directories which are also Samba shares. Because
> we use the DFS features of Samba, we have numerous intentional
> "dangling" symlinks in these directories. However, now this is causing
> getfacl to exit with non-zero status and spew lots of unwanted output to
> stderr.
> 
> A simple test case to reproduce the problem:
> 
>   #!/bin/sh
>   ln -f -s no_such_file foo
>   getfacl -RP . > dev/null
>   echo $?
> 
> Output on Etch:
>   0
> 
> Output on Lenny:
>   getfacl: ./foo: No such file or directory
>   1
> 
> I realise that upstream changed the behaviour at some point there, as
> the manpage description of the -P option differs between Etch/Lenny.
> However, we still need a way to ignore all symlinks - if the current
> behaviour is be design (I don't understand why this would be desirable),
> then can we have another option to completely ignore symlinks?
> 
> Thanks,
> Kevin.
> 
> 
> 
> 

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Bug#499076: Physical walk no longer ignores all symlinks, Nathan Scott <=