File::Find::find has incorrect results when operating on a foreign filesystem without nlink support on an OS that has nlink support #14920
Comments
From rmah@pobox.comCreated by rmah@pobox.comSummary Background When a foreign filesystems that do not support nlink is mounted on a Possible Resolution Negatives I understand that one can set $dont_use_nlink manually, but doing so Perl Info |
From @jkeenanOn Wed Sep 23 09:26:31 2015, rmah@pobox.com wrote:
Would you be able to provide an example? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Wed, Sep 23, 2015 at 05:07:40PM -0700, James E Keenan via RT wrote:
Well, File::Find is *supposed* to detect this on the fly, e.g. when
This wouldn't detect cases where find crosses a mount point boundary, -- |
From rmah@pobox.comJames E Keenan via RT wrote:
Well... sort of hard to do since it depends on one's environment, but, Background I found this problem by tracking down an issue I had building a module. If you take a module's source archive (that uses ExtUtils::MakeMaker) rmah@hillside:~/src/modules/Stdlog$ perl Makefile.PL If I move it to my home directory (so that it's on a local ext4 I tracked down the problem to the File::Find::find function and how it
NOTE: I found that if you explicitly set $File::Find::dont_use_nlink=1 Alternative Not sure how to give an small example, but you can do run this bash -- WIN_SHARE=/path/to/windows/share/mount mkdir $TEST_DIR $TEST_DIR/foo If you run that, the output *should* be: but instead you just get: because File::Find::find does not recurse into subdirectories. But Wait... Upon rereading docs, I note that it says that File::Find automatically "You shouldn't need to set this variable, since File::Find should ...but it does not. Perhaps this bug is a regression? In the _find_opt # a symbolic link to a directory doesn't increase the link count But... after digging a bit more, perhaps the problem lies in the # default: use whatever was specified For directories from a Windows share, nlink will be 2. To verify, just do: perl -le'@i=stat("dir/in/windows/share"); print $i[3]' on directory within a Windows share. BTW, I verified that perl's stat Perhaps just changing that line that tests $nlink < 2 to <= 2 will fix this? $no_nlink = 1 if ($nlink <= 2); Problem is, if you do this, I think it will always skip that optimized Anyway, sorry, this went on so long. Hope this helps. Rob P.S. Thanks for all the hard work you and everyone else as been doing on -- |
From rmah@pobox.comDave Mitchell via RT wrote:
Yes, I discovered this as well on a re-read of the docs and code. This is getting into an area I have next to no knowledge of but I did a 1) this problem (bad nlink counts for dirs) has been encountered by 2) It seems that some recommend FUSE filesystems be implemented with a So it's probably not limited to some weird peculiarity in my environment :-) Cheers, -- |
Migrated from rt.perl.org#126144 (status was 'open')
Searchable as RT126144$
The text was updated successfully, but these errors were encountered: