Mailing List Archive

Excerpts from the mail message of William Setzer:
) I seriously doubt this is a perl problem, but it sure does crash a
) perl build, so I thought I'd mention it just in case it becomes
) relevant down the line. I'm far from an AFS expert, but it appears to
) me that stat() may not be reliable in some versions of AFS, possibly
) due to a bug in the AFS caching. I put some debugging information
) around lib/Cwd.pm's fastcwd(), and here's what I see in Solaris 2.4,
) AFS version unknown, (... denoting deleted information), when trying
) to make perl5.001m:
) ...
) cwd = /afs/eos.ncsu.edu/users/w/wsetzer/work/perl/sol/perl5.001m/ext/Fcntl
) stat()ing .: target dev = 1, ino = 181141753
[...]
) lstat()ing w: dev = 1, ino = 628621358
) target dev = 1, ino = 262150
) ...
) lstat()ing users: dev = 1, ino = 262150
) target dev = 1, ino = 13631782
) ...
) lstat()ing eos.ncsu.edu: dev = 1, ino = 393222
)
) Oops! (The correct number is 393222). I can consistently get the
) 13631782 inode when running "make", but can't seem to get it when
) running a stat from the command line. Just FYI, in case it comes
) up again.

Hmmm. What exactly are you doing when running "stat from the
command line"? I've seen this problem from more than one company
that make NetWare-to-Unix products. They were completely unaware
that when it comes to directories in Unix,

/path/fred
/path/fred/.
/path/fred/*/..

should all have the same inode number. It was easy to see the
problem by doing:

ls -lid /path/fred /path/fred/. /path/fred/*/..

Perhaps you can give this a try.

The symptom of this under SCO Unix was that /bin/pwd could not
determine the current working directory path [because it does it
just like fastcwd() does in Perl]. A work around [which may be
how /bin/pwd works on AFS systems] is, when looking for the
matching entry on the next level up, to lstat "../*/." instead of
"../*". Simply change line 143 of perl5.001m/lib/Cwd.pm from

($tdev, $tino) = lstat($direntry);
to
($tdev, $tino) = lstat($direntry."/.");

and see if that improves things.

If it does then this can probably be implemented in more places
and perhaps made optional in case it carries other than a trivial
performance penalty.
--
Tye McQueen tye@metronet.com || tye@doober.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)

Tye McQueen:
: Excerpts from the mail message of William Setzer:
: ) ... stat() may not be reliable in some versions of AFS, possibly
: ) due to a bug in the AFS caching.
:
: Hmmm. What exactly are you doing when running "stat from the
: command line"?

I'm running variations on:

miniperl -e '($a, $b) = stat("."); print "$a, $b\n"'

All of them give the right inode.

: ls -lid /path/fred /path/fred/. /path/fred/*/..

All the same inode.

: Simply change line 143 of perl5.001m/lib/Cwd.pm from
:
: ($tdev, $tino) = lstat($direntry);
: to
: ($tdev, $tino) = lstat($direntry."/.");
:
: and see if that improves things.

$direntry may be a file or a directory, so it'll have to be wrapped
around an "if (-d $direntry) {} else {}". I tried this and it didn't
help.

Check out a portion of a recent run:

stat() .: 1, 628621358
[cd ..; stat direntries to find a match for "."]
lstat() a: 1, 628621314
lstat() b: 1, 628621316
...
lstat() u: 1, 628621354
lstat() v: 1, 628621356
lstat() w: 1, 13631514
lstat() x: 1, 628621360
lstat() y: 1, 628621362

If you see the full run, you'll notice that the inodes are sequential.
It turns out that the inode "13631514" is a directory underneath "w/"
that I have no permissions to see. A second run fails in the same
place, but with a different inode. This looks to me like good
evidence that it's a stat() bug.


William