--uQr8t48UFsdbeI+V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 02, 2004 at 09:38:03AM +0900, YAMAMOTO Takashi wrote:
> > Is there an RFC we can quote to Microsoft about this? Or is there an RF=
C=20
> > that we're not understanding right?
>=20
> i don't know.
> rfc1813 says that nlink is "the number of different names
> for the same file".  but it's obscure about ".." and ".".
> (and even the presence of them are vary.)
> maybe it's better not to assume that nlink is maintained in
> the unix-conventional manner, at least for nfs.

I think I found the general area of the problem, though I don't know the=20
code well-enough to continue. The fts source has the following comment:

 * The real slowdown in walking the tree is the stat calls.  If FTS_NOSTAT =
is
 * set and it's a physical walk (so that symbolic links can't be directorie=
s),
 * we can do things quickly.  First, if it's a 4.4BSD file system, the type
 * of the file is in the directory entry.  Otherwise, we assume that the nu=
mber
 * of subdirectories in a node is equal to the number of links to the paren=
t.
 * The former skips all stat calls.  The latter skips stat calls in any leaf
 * directories and for any files after the subdirectories in the directory =
have
 * been found, cutting the stat calls by about 2/3.=20

I think the problem is that the code's making an assumption which isn't=20
true for this NFS server. Unfortunately I don't understand the code=20
well-enough to know what exactly that assumption is. :-)

Take care,

Bill

--uQr8t48UFsdbeI+V
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAviWeWz+3JHUci9cRAmQkAJ0a8YbT69t5s7KoBS2S8q7FsoDOwgCff8sS
+ugGnDe5t2dWPDVLIqp7Udw=
=aGv8
-----END PGP SIGNATURE-----

--uQr8t48UFsdbeI+V--