🚀 go-pugleaf

In article <1989May12.183725.25380@ziebmef.uucp>, mcp@ziebmef.uucp (Marc Plumb) writes:

[text deleted]
> However, I've also heard that some people (Ameristar?) use the DiskKey
> as a unique file id.  So I'm not quite sure what is and is not allowed
> with it.
	
	For the first few revs of software we kept the NFS readdir cookie
	in the disk key field.  The latest rev of software hides all NFS
	state variables in an opaque data type stored around the Lock.
	NFS returns the diskkey set to the inode number of the
	file.  Such numbers may or may not be unique - we pass them on
	unprocessed from the server.  We do not rely on them 
	for internal purposes.

> Any other information about the semantics of ExNext() or the various fields
> of the FileInfoBlock (what does a fib_EntryType of 0 mean?) is also greatly
> appreciated.  Thanks!

	One bug we found a few years back was that the C data structure
	which defines the FIB had its comment field defined too large.  If
	you ref'ed the last few elements of the array it would crash certain
	programs.  We reported this to Commodore, but never checked if
	they did something about the definition.

> 	-Colin Plumb

					Rick Spanbauer
					Ameristar

> P.S. Does anyone have any ideas about directory formats?  I'm hovering in
> the vicinity of 24 bytes for an empty file with a single-character name and
> no comment, so I can promise cheap files, but whether to use an Amiga-style
> directory that's a lot of pointers to file headers or a CP/M-style
> directory that's basically an array of file headers proper is still an
> open question.  Then there's the Mac HFS scheme... does anyone know any
> other directory schemes?  Note that at the level I'm working, there is
> no way to ask for a file's name without size, date, flags, and comment, so
> splitting them up "to get all those big comments out of the way since dir
> never uses them anyway" is not useful.  You could argue for splitting
> up the information reported in a fib from the pointers to the file's disk
> space, but this means that growing a file would require you to update both
> places - one to record the location of the new data, and the other to record
> the new size.

	Well, here is one idea to help you bootstrap your filesystem.  A
	technique I use in my prototype NFS server to provide better
	directory semantics is to layer a new filesystem over FFS.  After
	all FFS does a fine job at handling reads/writes so why rewrite
	those immediately?  To speed directory handling, the server does it
	own directory caching/creation/deletion, etc to get at least a 10X 
	speedup over FFS Examine/ExNext, etc.  Of course the NFS server
	does consume quite a lot more memory but in exchange it does provide 
	faster dirops, symbolic links, etc.  I would urge you to consider 
	enhancing functionality rather than limiting it, ie don't reduce 
	names from 30 chars -> 24 chars - expand them from 30 chars -> 128 
	chars!  Add symbolic links, generalized attributes, more meaningful 
	protection, additional times information, etc.  The future has 
	multimbyte floppies, huge hard disks, etc.  Saving a few bytes 
	solves a problem that will not exist in a year.