Re^2: Can the special underline filehandle (stat cache) be cleared? (nlinks)

Ah, thanks for the suggestion about $File::Find::dont_use_nlink. I'll take a look at it. Unfortunately, I've spent enough time in File::Find that it doesn't look as complex as it used to (I've submitted patches for a couple bugs, as a result). :-}

Update: yup... it's no longer a guarantee that a stat was done on the file.

However, the more I look at File::Find, the more I want to follow your lead, and roll my own replacement for File::Find -- it's not exactly a stellar example of maintainable code.

Cheers,

Comment on Re^2: Can the special underline filehandle (stat cache) be cleared? (nlinks) Download Code

Replies are listed 'Best First'.
Re^3: Can the special underline filehandle (stat cache) be cleared? (when) by tye (Sage) on Oct 06, 2006 at 04:11 UTC
So, I'm curious. When you have `$File::Find::dont_use_nlink` set, in what case does File::Find not lstat a file ? - tye	[reply] [d/l]
Re^4: Can the special underline filehandle (stat cache) be cleared? (when) by ammon (Sexton) on Oct 10, 2006 at 20:46 UTC
At minimum, it doesn't provide a valid `lstat` on directories immediately below the search root: # file `perl -MFile::Find -e'$File::Find::dont_use_nlink = 1; find(sub + { lstat _ or print "$File::Find::name\n"; -l "" }, "/tmp")'` /tmp/opt: directory /tmp/hsperfdata_ammon: directory /tmp/.ICE-unix: sticky directory /tmp/xmmskde: directory /tmp/gpg-SRkPcN: directory /tmp/kde-root: directory /tmp/0165158219: directory /tmp/gconfd-root: directory /tmp/scrollkeeper-root: directory /tmp/hsperfdata_root: directory /tmp/gpg-ZV9kSX: directory /tmp/kde-steve: directory /tmp/ksocket-root: directory /tmp/gpg-h5tTLO: directory /tmp/1051437914: directory /tmp/gpg-I5lCsj: directory /tmp/.X11-unix: sticky directory /tmp/orbit-root: directory [download] (Of course, if your system equates `lstat ""` with `lstat "."`, you'll need to `-l` a non-existing file to clear `_`.) In the above example, there are sub-trees below some of those directories listed, and they do have a valid stat cache. I don't know, off hand, if there are any links in /tmp at the moment, so I can't say how symlinks are handled. I should note that this test is using File::Find version 1.07, which is a bit behind what's available on CPAN, but I don't recall the newer version behaving any different when I tested it. At any rate, the custom module I wrote ended up being 50% faster than File::Find, when tested on the 30K file tree mentioned in the original post, and the same speed as File::Find on very small trees. Best of all, though? It does exactly what I need. :)	[reply] [d/l] [select]