[Info-vax] Request description of UFS for VMS person

[Bill Gunshannon]

In article <ae561039-9f98-47a3-8f01-40b615214b1b at j9g2000prh.googlegroups.com>,
	AEF <spamsink2001 at yahoo.com> writes:
> On Apr 28, 10:17 am, "Bob Eager" <rd... at spamcop.net> wrote:
>> On Tue, 28 Apr 2009 12:37:23 UTC,
>>
>> koeh... at eisner.nospam.encompasserve.org (Bob Koehler) wrote:
>> > In article <176uZD2KcidF-pn2-uSusmdQq9... at rikki.tavi.co.uk>, "Bob Eager" <rd... at spamcop.net> writes:
>>
>> > > I needed to use it a couple of times in the early days (33 years ago)
>> > > but not since. My point in mentioning 'clri' is that someone here
>> > > thought that functionality was essential on VMS to tidy up a borked
>> > > directory, and (by implication) that 'Unix' was broken if it couldn't do
>> > > it. In practice, it seems that VMS *needs* it and Unix doesn't.
>>
>> >    Nobody said UNIX was broken if it couldn't do it.  The question was
>> >    why VMS has it, and an answer was given.  It was pointed out that
>> >    other OS needed some way to recover from the same situation (a
>> >    corrupt disctory), but no claim was made as to how that had to be
>> >    implemented.
>>
>> Nobody said VMS was broken! The VMS file system has many advantages. I
>> merely pointed out that ffs, at any rate, didn't seem to need a way to
>> recover from that situation.
>>
> 
> [My apologies if this appears twice. Google Groups told me it posted
> successfully, but that was after a long wait during which I edited my
> response in an external editor. I waited a while and it didn't show
> up. So I'm posting this again.]
> 
> The primary one I can think of is that everything on the volume really
> *is* a file. Everything in the volume is "transparent". In Unix, at
> least the ones I have access to I don't know how to dump the super
> block or inodes. And on one of them I can't even dump a directory!

Again, it is not that Uix won't let it be done, it is that either you
just don't know how or you lack the needed permissions.  If you really
are interested in learning some of this I would suggest setting up a
system or two of your won so you have root privs and play with it.

> 
> So can you or anyone else tell us more of the advantages? How about
> disadvantages?

Greatest advantage is functionality.  Unix doesn't tie my hands.
Greatest disadvantage is functionality.  Unix doesn't tie my hands. 
(which could be a real problem if I don't have a clue what I am doing.
I have seen people open directories with vi.  :-)

> 
> And on the Unix side if there is a way to read the super block and
> inodes? 

If there is a way, what?  Or did you mean is there a way?  Answer is, yes.
But there is not (that I know of) an existing utility for that.  But you
can write one.  

Look at this piece from /usr/include/sys/dirent.h:

/*
 * The dirent structure defines the format of directory entries returned by
 * the getdirentries(2) system call.
 *
 * A directory entry has a struct dirent at the front of it, containing its
 * inode number, the length of the entry, and the length of the name
 * contained in the entry.  These are followed by the name padded to a 4
 * byte boundary with null bytes.  All names are guaranteed null terminated.
 * The maximum length of a name in a directory is MAXNAMLEN.
 */
 
struct dirent {
        __uint32_t d_fileno;            /* file number of entry */
        __uint16_t d_reclen;            /* length of this record */
        __uint8_t  d_type;              /* file type, see below */
        __uint8_t  d_namlen;            /* length of string in d_name */
#if __BSD_VISIBLE
#define MAXNAMLEN       255
        char    d_name[MAXNAMLEN + 1];  /* name must be no longer than this */
#else
        char    d_name[255 + 1];        /* name must be no longer than this */
#endif
};

Read the comment and then look at the structure.  The maping between the
inode and the file name is contained in the directory, pretty much where
one would expect it to be.  Write a utility to read directories and print
out that mapping.  The need for which totally evades me. :-)


>          So much for "everything is a file in Unix".

What from what has been stated so far disproves this?  While it has
been demonstrated that in some cases structures have been imposed on
various parts of the Unix File System everything, right down to the
raw disk, can be accessed as a file, one byte at a time, if you want.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>