std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/12/85)
Date: Wed, 11 Dec 85 17:52:17 EST From: Arnold Robbins <arnold%gatech.csnet@CSNET-RELAY.ARPA> Chapter 5: Files, Directories, and File Systems 5.2.2 Directory Operations While I am very pleased to see the BSD style directory access routines included, I am dismayed at the lack of seekdir() and telldir(). These routines are essential for traversing directory subtrees when one has a limited number of open files allowed. Something should be done to try and included them. --------- 5.4.2.2. Description (of creat()) ... If the file is a special file or a FIFO pipe, it is opened for writing. Should be ".. or a FIFO file...". A general note on _creat()_. It seems that whenever _open()_ is cited in the references, _creat()_ is not. Either all the references should be changed, or some note should be added explaining this. I don't think that just stating that creat (path, mode) is equivalent to open (path, O_WRONLY | O_CREAT | O_TRUNC, mode); is enough. (Of course, I could be wrong....) [ I'd think establishing that identity should be sufficient. -mod ] ----------- 5.5.3.4 Errors (returned from mkfifo()) Why are EIO and ENFILE possible errors? EIO says "error writing to the file system". ENOSPC (couldn't extend the directory) should handle that. ENFILE seems to me to be wrong -- there is no reason to *open* the file in order to create the fifo. mkfifo should just make a directory entry and set the right bits in an inode (yeah I know, that is an implementation thing). The point is that no files should be opened here. --------- 5.6.2.4 Errors (for rmdir()) [EBUSY] The directory to be removed is the mount point for a mounted file system. What is a mounted file system? I thought that all references to such things had been removed.... This is probably just an oversight on the part of the editor(s). ----------- 5.7.1.2 Description (of <stat.h>) S_IWXG Read, write, and execute permissions for the group... Should be S_IRWXG. This is undoubtedly a typo. S_ISUID ..... This bit shall be set only by the the function _chmod()_. It should be cleared on any open for writing. The word "the" is printed twice in the actual document. I did not make a typo :-). Also, I would prefer "It shall be cleared on any open for writing". S_ISGID Same comment about "should" vs. "shall". [ Seems like the reason was that that would outlaw some existing systems. -mod ] st_ctime Why does the pipe() system call change this field? ----------- 5.7.4.2 Description (of chmod()) ... The value _chmod_ shall set the access permission portion of the named file's mode according to the bit pattern contained in mode. Delete the first two words of this sentence and capitalize "chmod". [ We never capitalize anything which is really in lower case, even at the expense of filler words at the beginning of the sentence. -mod ] ---------- 5.7.5.2. Description (of chown()) Describes what happens to the setuid/setgid bits if successfully invoked by a non-superuser (they're cleared). All fine and good, but what happens to those bits if chown is invoked by the superuser? This should either be stated clearly or explicitly left undefined or implementation dependant. ------------ 5.7.6.5 Notes (on utime()) What about st_ctime? Most Unix implementations (all?) do not allow this to be reset. Shouldn't something be said about it? Volume-Number: Volume 4, Number 13