args to fchmod() and chmod()
Greetings, all. 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. 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? 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? (*) sys/stat.h on different platforms define different subsets of the bits named in the Posix specification. In light experimentation on the platforms I have readily available, I have not seen any unnamed bit affect the value of the mode returned from stat(). How can I best define the valid bits portably? Thank you, all, for your attention. Terry. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: args to fchmod() and chmod()
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
Re: args to fchmod() and chmod()
At 11:10 2003-01-20 -0500, you wrote: Terrence Enger writes: [snip] 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 When I tried fchmod() with each single bit set in the new mode, OS/400 returned an error for each value except S_IXOTH, S_IWOTH, S_IROTH, S_IXGRP, S_IWGRP, S_IRGRP, S_IXUSR, S_IWUSR, S_IRUSR, S_ISGID, S_ISUID. The file type bits came to my attention first because they caused a failure during sanity.sh. 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. Over the last several days, I have managed to read the specification both ways. (If I *really* cared, I suppose I would have to spend the ink to print that page out grin.) [snip] As per the above spec, the valid bits are precisely: (S_ISUID | S_ISGID | S_ISVTX | S_IRWXU | S_IRWXG | S_IRWXO) Well, uh, yes. But not all libraries define all these names. I have looked at all the stat.h which are readily available to me. These are OS/400 V5R1, Linux gcc 2.95.3, Mingw GCC 3.2, and Visual C++ 4.0; in each case I used the default setup for compilation. Only the Linux compiler defines all these names. OS/400 comes close, omitting only S_ISVTX. The two Windows compilers give names to the three on bits of octal 0700, but have some disagreement about what the names should be. (Sorry to seem dense, I allowed myself to be intimidated by the many differences between the platforms. On cooler consideration, most of those differences do not impact this task.) Thank you for your help. Terry. -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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
