gaspodethewonderdog has asked for the wisdom of the Perl Monks concerning the following question:

Hi guys... I'm running a perl script from a Tru64 UNIX system. The script I am running is trying to traverse a VMS file share, that is being exported to look like a UNIX network file system.

When using the find command (ie find . -name "*.dif") it will find all of the files, directories and subdirectories.

When using File::Find though, the find command will not travel down subdirectories. I have checked, and as far as ls is concerned it is a directory, all of the subdirectories pass a -d test, yet the tools refuse to do a deep directory search on these VMS file systems. When I run the same code on a local file system it works as intended, so it isn't a coding error.

Is it possible that there is a parameter that I need to set to tell Find to do a deep search on a network file system, or any other thoughts on things to check? It just seems odd that there is this kind of an issue, and I'd rather not run a `find` command if I can help it.

Thanks guys!

Greg

  • Comment on Issues with File::Find and Network Mounted Disks

Replies are listed 'Best First'.
Re: Issues with File::Find and Network Mounted Disks
by Corion (Patriarch) on Jan 25, 2006 at 19:49 UTC

    This is a longstanding bug/optimization in File::Find - you want to set $File::Find::dont_use_nlink = 1, which makes File::Find behave in a sane manner. Your file share seems to fall under the "and a couple of others" category of problematic filesystems that were sacrificed for speed.

[reply]
[d/l]

      s/optimization/"optimization"/; s/speed/a speed-up for rare uses and a slow-down for common uses of it/;

      "use nlinks" should be something that is only done when requested and you should only request it if you are selecting files only based on the file name and you don't care if your code rather easily breaks in the face of all-too-common file systems that the File::Find maintainers still try to pretend don't matter much (and if the speed-up is that important to you). Using it otherwise actually makes File::Find run slower than it needs to.

      Yes, I've notified p5p of these problems. But I gave up doing so many years ago. Yes, I realize that they now claim to auto detect when it would break things, but their previous (multiple) claims of safe auto detection were laughably incomplete (and I notified them of this) so I doubt (especially since we still get nodes like this) that the new detection is sufficient.

      I particularly like "If you do set $File::Find::dont_use_nlink to 1, you will notice slow-downs". I notice speed-ups. But please, state it more forcefully and it will surely become true. (:

      Now, the speed-up when only caring about file names (and only about suitably vanilla Unix file systems) is more significant than the speed-up I get by turning off their "optimization" for the more common uses of File::Find, so I'm not that surprised that some have formed an emotional attachment to it. But I've been burned by File::Find just plain not working so many times (I mostly stopped using it directly long ago but I still sometimes run into tools that try to use it) and I find my emotional attachment to wanting things to actually work to validly trump concerns of speed (especially since my way is faster most of the time anyway).

      - tye        

[reply]
[d/l]
      Thanks that was exactly what I needed... I kept poking through all the Perl CD Bookshelf files and couldn't find a thing... the dont use nlink parameter was just what I needed.
[reply]
Re: Issues with File::Find and Network Mounted Disks
by demerphq (Chancellor) on Jan 25, 2006 at 19:56 UTC

    Maybe you need to turn on 'follow'? The documentation talks about not following symbolic links unless you specifically say to do so.

    ---
    $world=~s/war/peace/g

[reply]

Back to Seekers of Perl Wisdom