Working with a list of files and letting chmod do the loop is probably faster than looping over chmod statements. But if your list of files is very large, you could run out of memory. (Very unlikely, but there is a theoretical limit there.)

Personally I would suggest working with whatever style fits the surrounding code the best. With File::Find that would be one file at a time, just do the chmod in the callback.

(Actually I would be inclined to go to the shell and just do a chmod -R ..., but it sounds like you have been down that route...)

Working with a list of files and letting chmod do the loop is probably faster than looping over chmod statements. But if your list of files is very large, you could run out of memory. (Very unlikely, but there is a theoretical limit there.)

I'll furthermore add that, with many implementations of 'chmod' the number of args is limited,
and you'll probably hit a 'arg list too long' error way before you exhaust your memory...
(For example on my linux box I'm limited to around 12900 files as arguments...)

To my mind you'd definitly better use the one-at-a-time strategy...

Note : This problem also occurs with a lot of others file related tools : rm, ls...

"Only Bad Coders Code Badly In Perl" (OBC2BIP)

Technically, the underlying chmod(2) system call only takes two arguments (the mode and the path). So no matter how many filenames you pass to perl's chmod it's going to devolve into multiple system calls somewhere underneath anywhere.

On a linux box, this is easily illustrated by the following experiment (better carried on the /tmp directory):

 strace -e trace=file perl -e 'chmod 0777, "a".."z"' 2>&1 | tail -26

One will see 26 chmod system calls.

-- stefp

You might consider system 'find'.

$ find /the/dir -name \*.dat -not -perm 644 -exec chmod 644 \{\} \;
[download]

Whatever solution you use, you can prune statting all regular files in a dir whose mtime is prior to the last run. chmod acts on the inode, not the file, so the directory times are what counts.

After Compline,
Zaxo

Actually such a script is replaced. And I wouldn't know how to elegantly and efficiently have a list with exceptions put in that code. But thanks anyway (the hint with mtime and last run is a good one (just like the prior postings contained good hints - thank you, Monks! :)

Regards...	Stefan
you begin bashing the string with a +42 regexp of confusion

Using the command find instead of File::Find is not a bad thing per se. But as you do it, you will fork a chmod command per matching file. Since you are concerned by performance issue, let us say it may be better to optimize by bundling as much files as possible in an exec command by using xargs:

find /the/dir -name \*.dat -not -perm 644 | xargs chmod 644

To be on the safe side and to deal correctly with weird file names (like windoze filenames with blanks), it is even better to use the null character as a file separator:

find /the/dir -name \*.dat -not -perm 644 -print0 | xargs -0 chmod 644

-- stefp

We had a slew of directories that were created with the wrong permissions on a few of our servers recently. In an effort to make our admin's life a little easier I whipped up this bulk permissions changing script.

It doesn't do exactly what you want, but it might give you a head start. It recurses through the directory trees offering to change any to mode 755 that are set something else. A nice feature is the verbose logging and the creation of a bash friendly undo script when it's done.

Parts of this code were from when I was a younger, less-wise monk so I don't use Getopts or File::Find - but this isn't terribly complicated so it doesn't hurt anything. If you are going to start your own from scratch you'd be wise to check those out. It also doesn't bother with checking the owner since root happened to own all files in this particular case.

Good luck! Click on the READMORE tag for the code.