in reply to File::Find bummers on an NFS volume.

From the little I can get out of the oracle, it should've been turned on all along, but for some reason wasn't. Maybe you're using an outdated version of File::Find or what have you.

If you look at the spec for NFS, RFC 1094, you will see that nlink is "the number of hard links to the file (the number of different names for the same file)". My theory is that without the dont_use_nlink option, the File::Find system refuses to recurse into what it perceives is an empty directory.

Replies are listed 'Best First'.
Re: Re: File::Find bummers on an NFS volume.
by petdance (Parson) on Jul 31, 2001 at 20:44 UTC
    Your theory sounds pretty good, and this code 
            if ($nlink == 2 && !$avoid_nlink) {
            # This dir has no subdirectories.

    [download]
    seems to back that up.

    So what does one do to go about getting the pod patched to mention NFS and Samba as well as AFS?

    xoxo,
    Andy
    --
    <megaphone> Throw down the gun and tiara and come out of the float! </megaphone>

[reply]
[d/l]

      Don't just patch the POD. Patch the module! See RE: RE: File::Find. I'm not aware of a single modern system where having that on by default makes sense. Any system that supports CD-ROM drives should not have it turned on by default, for example. And it is all Win32 file systems, not just remote samba file systems that are incompatable with it. Most Unix systems support quite a few file system types that don't follow the "nlink" rule.

      Of course, I and others have tried to patch this multiple times and none of the patches have ever been accepted. I think File::Find just has too much bad history behind it and what we really need is a replacement that

      • doesn't require the use of a callback
      • never tries the "nlink" trick
      • (and so) always stats each file just before transfering to the user's code so that the user can just stat _ (or -f _, etc.) to make most uses run faster (yes, that's right, the "nlink" trick makes certain trivial uses of File::Find run quite a bit faster but it also forces non-trivial traversals to be slower!).

      File::Recurse might be such a replacement but I'm worried that it isn't being maintained. So I'd rather people put work into something like that (and getting it bundled with the base Perl distribution) than banging their head against the brick wall that is the "nlink" trick in File::Find.

              - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
        How would it transfer to the user's code if it didn't callback? File::Recurse only populates a hash with filenames keyed by directory; it doesn't call anything.

        I think a callback is natural; however, there might also be an interface that populates hashes or arrays.

[reply]
        Don't just patch the POD. Patch the module!

        I probably agree that the default should be changed, but what I'm hearing is that it's been suggested and rejected. Given that nobody's going to change it, then I think that we should at least patch the POD so that future users of the module don't go through the same thing I did.

        The two options are not mutually exclusive. We can do BOTH.

        So my question still stands: What do I need to do to get the POD patched?

        xoxo,
        Andy
        --
        <megaphone> Throw down the gun and tiara and come out of the float! </megaphone>

[reply]

In Section Seekers of Perl Wisdom