> -----Original Message----- > From: Ronald F. Guilmette <r...@tristatelogic.com> > Sent: Tuesday, January 14, 2020 8:16 AM > To: austin-group-l@opengroup.org > Subject: Re: A question on file flags after fork > > In message <mailto:1676199645.11146898.1578981958...@mail.yahoo.com>, > Shware Systems <mailto:shwares...@aol.com> wrote: > > >Short answer, because both file descriptors reference the same file > >description... > > OK. I see where I took a wrong turn now, however I must say that I cannot > blame myself for having done so. The > language being used for the base concepts here is exceptionally stilted. We > have -descriptors- and then we have > file -descriptions-. I get it now, but I cannot help but wish that the > original drafters, way back when, had > elected to be a bit less clever and bit more obvious in their coinage of the > relevant terminology here. The > term "file desctriptor" was grandfathered in from the ancient times of UNIX. > So that was cast in stone and > could not be reasonably changed. But I would have been a LOT happier if > those standard drafters, back in the > day, had elected to call what is apparently now called a "file description" > something else... a "purple > aardvark" or basically anything other that the thing they finally settled on, > which is extraordinarily subject > to misinterpretation, being as it is, so close to the term "file descriptor".
I imagine people were reluctant to use "file table entry", as that implied a certain implementation (a table). > Moving ahead, now that my misreading has been corrected, I'd like to just > throw out a trial balloon and note > that it would be pragmatically useful to provide some attributes that are > currently associated only with "file > descriptions" also for file descriptors. O_NONBLOCK is the one that is most > immediately apparent to me, but I > can readily imagine usefulness also for permitting things like O_APPEND and > even O_RDONLY and O_WRONLY to be > applied selectively to individual file descriptors, rather than to (shared) > file descriptions. I will happily > elaborate on a real-world scenario in which this would have been most useful > to have, if anyone is interested, > and also the ugly ccode contortions that had to be applied in order to > work-around this particular non- feature, > which I am now aware is 100% standard conformant. The point of O_RDONLY and O_WRONLY being fixed is that file access permission checking is done only during the open(); the resulting file descriptor can be passed on to executables with a different (lesser) set of permissions. Similarly, with O_APPEND, you want to make sure that, e.g., earlier log entries cannot be destroyed by later ones by processes outside of your control. I agree that the case for O_NONBLOCK is less clear and was surprised that this is not stored as part of the file descriptor (although the name does give it away).
