[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Youngman
Subject: Re: Problem with find + AFS + acl="l"
Date: Fri, 3 Nov 2006 18:30:00 +0000

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]