There's not much more you can do from here, apart from the fact that you could be statting the file twice. You should be using
-f $_ and -M _ < $age
but this will only give marginal improvements. If you install Perl on the distant server and run the script from there (i.e., locally, so as to exclude the network traffic cost from the script), does it run any faster?
Unless you've modified the default registry settings, NT will reflect a change in a file timestamp in the directory timestamp as well. You may be able to use this as a test to see whether you have to stat all the files in the directory to see which file changed.
On the other hand, I can't remember whether under NT it is possible to count the number of links to the current directory to determine whether there are any children directories (and thus, whether you have to traverse it or not to continue descending the tree).
perl -le 'print( (stat $_)[3] ) for @ARGV' . .. /tmp
And tr/'/"/ for Win32
Damn, I just tested and it doesn't work. On Unix, if the number of links to '.' is 2, then you know it is referred to only by itself and its parent. If the numbe is higher, then a subdirectory must be referring to it as a parent. Unfortunately, on Windows 95 and Windows NT, nlink always returns 1.
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u' | [reply] [d/l] [select] |
| [reply] |
i believe -M $_ < $age and -f _ will offer a little more improvement over grinder's suggestion. (this assumes there will be fewer modified things than files, so the second test is performed less often. )
but i'd use Win32::API and call native OS commands. they *should* be faster. you can get documentation for the win32 sdk online at msdn
~Particle *accelerates* | [reply] [d/l] |
| [reply] |
Eh hemm? Win32::ChangeNotify?
no. as i understand the original poster's requirement:
I have access to a huge fileshare (Win NT) and want to get an overview of what's happened the last n days
weini want's a post-fact report. Win32::ChangeNotify -- from the doc:
Monitor events related to files and directories
allows you to monitor files and directories in real-time. your suggestion meets a different requirement than that mentioned by the original poster.
~Particle *accelerates*
| [reply] |
You could try forking a few processes and divide the work up between child processes - having each child read recursively down a separate directory will speed things up. You could feed it a list of directories to open - or even have your application find directories - and fork off processes based on the number of directories.
Rich36
There's more than one way to screw it up...
| [reply] |