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

[Bill Gunshannon]

In article <75tm0vF1a2nhsU3 at mid.individual.net>,
	billg999 at cs.uofs.edu (Bill Gunshannon) writes:
> 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.
> 

OK, I guess because I have never had a reason to do it I just never looked,
but I did now.  You want the inode numers of files?  "ls -i".  So, if one
was paranoid enough and actually cared, there is no reason why one can not
keep a copy of that mapping around just incase something shows up in the
lost+found directory.  :-)

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>