Re: args to fchmod() and chmod()

[Larry Jones]

Terrence Enger writes:
> 
> I notice that cvs in several places executes fchmod() or chmod(), and that
> in some cases the new mode argument is the mode returned from an earlier
> call to stat().  This value typically includes the file type.  
> 
> On most platforms this causes no problem, but OS/400 complains that "the
> value specified for the argument is not correct".  Indeed, the
> documentation of chmod() at
> http://www.opengroup.org/onlinepubs/007908799/xsh/chmod.html lists the bits
> which it can change and specifies that errno=EINVAL is a possible result,
> so I think that OS/400 is arguably correct.

Are you certain that it's the file type bits that are causing the
problem?  If so, I'd say that OS/400 is definitely *incorrect*.  The
above-referenced specification says that chmod sets the SUID, SGID,
sticky, and permission bits of the file to the "corresponding bits" in
the argument.  There is no requirement that non-corresponding bits of
the argument be set to any particular values.

> Does anybody forsee possible bad results from masking the mode argument
> down to the valid bits?  Would the "official" cvs be willing to accept a
> patch to this effect?

I can't see that it hurts anything, other than some people's
sensibilities.

> If this is a good idea, perhaps some expert can answer a couple of questions:
> (*)   Where should I define the valid bits?  Would anybody volunteer to help
> me with the configuration tools?  Would anybody be willing to take over
> that part of the work?

As per the above spec, the valid bits are precisely:

        (S_ISUID | S_ISGID | S_ISVTX | S_IRWXU | S_IRWXG | S_IRWXO)

-Larry Jones

Nobody knows how to pamper like a Mom. -- Calvin