🚀 go-pugleaf

In article <2826@sbcs.sunysb.edu> rick@sbcs.sunysb.edu (Rick Spanbauer) writes:
>In article <1989May12.183725.25380@ziebmef.uucp>, mcp@ziebmef.uucp (me) 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.

Thanks for the info.  Now what about doing NFS to an Amiga volume?
How do you translate a FIB returned by ExNext() into readdir() or whatever?
Do you translate the DiskKey into the inode number or something?

> 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.

In the 1.3 Includes, the comment fields is now 80 bytes followed by 36 bytes
of reserved space.  Annoying, since I let a user set a 255-byte comment.

>> 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

> 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.

I have 127-character filenames, and can go to 255 if anyone complains.
The question of what to do with names more than 107 characters long when
returning FIBs is an open one.  (First time round, I'll just truncate.)
When I mentioned 24 bytes, that's the size of a file header block with
a short name.  I can add 127 bytes of name, 255 bytes of comment, and
a lot of pointers to extents to make it a lot larger.

I'd like to add symlinks, more dates, better protection, etc., but the
new features aren't understood by existing software, and I don't know
how to design the interfaces.  Multiple links, arbitrary graph file
systems (the parent of the current dir is the one you came in via),
symbolic links, mount points, more timestamps, etc. are all useful
things, but I'd like to either design a whole new FS interface (with
no BPTRs anywhere and using exec I/O messages), and/or get at least one
other person to agree with me on the best way to tack it on to the
existing framework.

If a file has multiple links, should the comment go with the name or the
the file?  Should the hidden bit just be a convention observed by directory
listing programs, or should it be enforced by ExNext?  If it is enforced,
how to find the names of hidden files?  (How about ExNext returning hidden
files if there are no non-hidden ones in the directory?)

I'd be perfectly happy to add features to the bottom layers if someone can
show me a good interface to them.  Consider it a challenge!  But for now, a
file has name, comment, size, timestamp, parent, and protection bits.  I
have added a comment to the root directory and the ability to seek past the
end of a file, but no more obvious extrapolations come to mind.  I'm seriously
considering allowing Unix-style create-and-delete files without names, but
it's tricky.

Thnaks for your comments.
-- 
	-Colin Plumb