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
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
