Re: Missing files & File::Find.pm

Looking at the source code, it appears that the Windows Platform SDK defines PATH_MAX as 260, and that is more than 260 bytes long is going to cause problems.

The chdir() in the Microsoft C run-time always does a GetCurrentDirectory() after a SetCurrentDirectory() and it will fail if the absolute path name is more than 260 bytes, even if no single directory name is that large.

There might also be a bug in Perl or the C run-time so that a path name that large overwrites a buffer causing the file names to appear very weird (this is just speculation).

You might be able to get File::Find to work using the "no_chdir" option-- see the File::Find documentation.

Comment on Re: Missing files & File::Find.pm

Replies are listed 'Best First'.
Re^2: Missing files & File::Find.pm by sbas013 (Initiate) on Feb 08, 2007 at 08:50 UTC
Oh no - RTFM! I was a bit sceptical that I would get ANY replies thinking File::Find was just too boring for someone to show any interest. That's put me in my place. I will try the no_chdir option & see how I get on. If this doesn't work I will be forced to have a look at wsh / vb, what a shame! Thanks for the pointer, very much appreciated. Cheers, Simon	[reply]
Re^2: Missing files & File::Find.pm by Corion (Patriarch) on Feb 08, 2007 at 09:11 UTC
Note that you can circumvent the PATH_MAX limit by using UNC filenames, as discussed in the CreateFile documentation by Microsoft. Some short testing shows that not changing the directory seems to work: `perl -MFile::Find -le "for $d (@ARGV) {print qq(Scanning $d);find({no_ +chdir=>1, wanted=>sub{print $File::Find::name}},$d)}" \\?\Q:\ Q:\` [download] Without the `no_chdir` option, scanning the first entry (`\\?\Q:\`) fails immediately.	[reply] [d/l] [select]