The same thing will occur if you try to use File::Find on Win32 upon a Samba-mounted drive. Reading the source is pretty instructive in this case. In a nutshell nlink is the reference count of the inode.

When considering directories, it stats the current directory ('.') to find out how many references the inode has. If it has two, then it may be inferred that the inode is linked to by the directory itself and its parent directory. By extension, that means that it has no subdirectories, therefore there is no point going any deeper. Thus the search stops going any deeper.

This turns out to be a very useful speed optimisation, especially when finding depth first, because you don't have to go into the leaf directory, stat every directory entry, just to learn that there are no more subdirectories.

Unfortunately, not all filesystems behave this way, notably the Andrew File System (not that I have ever knowingly worked with one) and especially Samba-mounted drives. And, as you say, on NFS shares.

The code can't (maybe it is too expensive to deduce) determine itself whether the number of inode links is reliable or not, which is why you sometimes have to give it a manual hint by way of

  $File::Find::dont_use_nlink = 1;

--

g r i n d e r