Hang about ! , if I have this correct - you want to traverse an NFS tree and action files that match your logic, but you are concerned about the FS changing under your feet. Is it possible you could nibble away at the output of whichever finder mechanism you choose, thus diminishing (hopefully) the time between 'knowing' about a file and actioning it?

This is off the cuff code- OK!

open ( FIND , '|' , '/usr/bin/find' , @findargs ) || die $!;
while ( <FIND> ) {
 
 if ( $_ =~ /$myfileMatch/ ) {
    if ( -M $_ > 14 ) {  # file modified more than 14days ago
        # delete file magic
    }
    else { # compress file magic }
 }

}
[download]

This way open is happily running find forked, whilst the script does dirty work. Of course if you are compressing monster files across NFS from a filer there is going to be a performance hit of somekind.

Of course this may not be what you want, and doing it this way I strongly recommend the script keeps a record of exactly what the hell it's doing.

Update: Since you are concerned about files that are ageing as opposed to new files, it perhaps does not matter too much that new data is added to this tree as the script runs. Reading back methinks that it's better to build a static list of matching files to operate on, then run through that list at the end of search, checking that they indeed -e exist.

I also hope you only have to deal with NFS to the filer, coz SMB op-locks might cause you pain