Re: Problem with find + AFS + acl="l"

[James Youngman]

On 11/2/06, Daniel Richard G. <address@hidden> wrote:
> On Wed, 2006 Nov 01 20:58:21 +0000, James Youngman wrote:
> >
> > If we see a DT_UNKNOWN before anything else in a directory, we
> > wouldn't know whether to assume it's a directory or not, unless we had
> > previously seen a DT_DIR for "." or "..".
>
> I take it there's a good reason for not using scandir(), with a custom sort
> function... always forcing "."/".." to the top seems like it would make
> life easier.

Lack of support / portability I would guess.  It's not in POSIX and I
don't think there is a replacement in gnulib.

> > >If not, it might be sufficient to check if the directory's canonical
> > >path is under /afs. (You're never going to have AFS mounted on e.g. /usr
> > >or /mnt/afs.)
> >
> > It's not always possible to figure out the canonical path (for example
> > if a parent of the start point has no execute permission).
>
> AFS in many respects disregards the Unix mode bits, giving primacy to ACLs.
> If you could enumerate the ways in which a canonical path might not be
> obtainable, I can test to see if any of them apply to AFS.

A typical example I suppose is that ".." is not searchable (this does
not prevent getcwd() working on all systems).  I can't think of
another example right now.  Maybe there could be cases where some
ancestor directory is mounted from an unreachable NFS server (while
"." is a local filesystem or is mounted from a different, reachable,
NFS server).

James.