question for the "base gurus"
René J.V. Bertin
rjvbertin at gmail.com
Wed Jan 25 09:10:08 UTC 2017
On Tuesday January 24 2017 19:14:28 Brandon Allbery wrote:
>On Tue, Jan 24, 2017 at 6:53 PM, René J.V. Bertin <rjvbertin at gmail.com>
>> 0775 (00000001:11111101) turning into 0255 (0000000:10101101), there's no
>> logical explanation (involving umask()) for that, is there?
>That is what you'd get if the *umask* were 0255.
Why yes indeed, but then the question becomes why the umask would sometimes get set to 0255. Does that sound like a value that base might use in certain conditions? I never use umask myself, one of those things I shoot myself in the foot with too easily.
The setmode() manpage warns about transient changes to umask (on Linux and OS X) but the only evidence I find for that (in v. 0.8.3) is this:
* Get a copy of the mask for the permissions that are mask relative.
* Flip the bits, we want what's not set. Since it's possible that
* the caller is opening files inside a signal handler, protect them
* as best we can.
(void)sigprocmask(SIG_BLOCK, &signset, &sigoset);
(void)umask(mask = umask(0));
mask = ~mask;
(void)sigprocmask(SIG_SETMASK, &sigoset, NULL);
I don't know what the umask() function does internally but I'd hope that would be one of the more exhaustively tested (and no-longer-evolving) system functions. Maybe the old-style obfuscated-C like umask() statement can confuse modern-day optimisers in such a way that the operation has side-effects under stress? Sounds unlikely, no?
Am I missing a reason why the umask() function would interact with the filesystem?
More information about the macports-dev