On Tue, Sep 02, 2008 at 08:06:51PM +0200, Jim Meyering wrote: > Good idea. > At least for chmod, it is not only possible, but the optimization > would be essentially free, since chmod already has the required stat data.
Yeah, I thought it was a good idea too. > AFAICS POSIX > (http://www.opengroup.org/onlinepubs/007908775/xsh/chmod.html) > allows the behavior you propose. That same feature was even > requested a few years ago, but no one implemented it. Thanks for the lead - I had no idea where to go looking for POSIX specs. But you got the wrong URL. The URL above refers to chmod() the function. What we needed was chmod the utility. Here it is: http://www.opengroup.org/onlinepubs/007908799/xcu/chmod.html And, if one wants to be REALLY pedantic, it looks like the file node is supposed to be changed each time. For example, here is an extract: + If perm is not specified, the + operation will not change the file mode bits. If who is not specified, the file mode bits represented by perm for the owner, group and other permissions, except for those with corresponding bits in the file mode creation mask of the invoking process, will be set. Otherwise, the file mode bits represented by the specified who and perm values will be set. Here it says that the bits will be set. Unfortunately, they do not say something like "set unless already set". If the feature is to added, it will be a non-standard option. > A patch would be welcome. I totally agree. > If you're not interested, let me know in any case and > I'll add it to the TODO list. I think I will let you add it to the TODO list. :-) > For chgrp (probably chown, too, at least in some cases), it's not > as obvious, since the current implementation does not stat files > before changing permissions. So, to do what you want would involve > adding a stat call per file to get owner/group in order to avoid(maybe) > the offending ownership-changing syscall. That would not be an > improvement. As far as speed is concerned, you are right that an extra stat() would usually not improve matters. (Would it be an enormous penalty? I doubt it.) But users of file integrity checking systems like myself will be grateful for the change of behavior. -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossen to do, start with RTFM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
