Hi,
*IF* POSIX or general use mandates that chmod(2) should not change
ctime if no change really occurs, this should be fixed in the
Linux kernel itself.
Fixing it in user space in the chmod(1) utility is wrong, because it
could introduce user-space race conditions.
For example:
timestamp 1: perm is 0500
timestamp 2: perm is 0700
timestamp 3: perm is 0500
we would expect c_time to be timestamp 3 at the end of this flow.
Now imagine that you have two processes. Process one wants to set
perm to 0500, process 2 to 0700. Imagine it works as follows:
process 1 process 2
stats file, gets perm 500
stats files, get perm 0500
set permissions to 0700, ctime changes
set perm, no real change,
so don't do anything
WRONG! permission is 0700!
(one could argue that the overall result is undefined if the two
processes are scheduled in parallel anyway; however there seem to be
something wrong in the user-space semantic here anyway)
(in general, any "I check manually, then I set" method is wrong,
unless it is done atomically, which is not the case for user space
and can only be guaranteed with kernel locks with currently used
Linux kernels)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
