🚀 go-pugleaf

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