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

[AEF]

On Apr 30, 9:05 am, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> In article <ae561039-9f98-47a3-8f01-40b615214... at j9g2000prh.googlegroups.com>,
>         AEF <spamsink2... 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.

The whole point of "everything in Unix is a file" to me means that you
can treat all these things as files the same way. In ODS-2 everything
is a file or is in a file. You can dump any file, even the pagefile! I
don't have to write no stinkin' utilities. I can use file commands on
VMS files. I can't use file commands on the super block or an inode.
So in my book they are not "files". If files are as you define them,
then the claim "everything in Unix is just a file" becomes
meaningless.

Unix will let it be done. Fine. No one will stop me from walking from
New York to Los Angeles either.

I have my own system. I have root. No, I don't know how. So super
blocks and inodes are not really files. They don't have their own
inodes. They can't be written as a path. Just how exactly are these
creatures files?! If I have to spend a lot of time hunting down the
right documentation and hours, days, whatever writing some stupid
utility that hunts down the bytes and assembles them (into files!),
then these are not files. They are like car parts. Yes, you can build
a factory and put them together, but they are not a care; they are
parts. Structured, yes. Findable, yes. Readable? Yes. Put
togetherable? Yes. Documented somewhere in a library, bookstore, or
Internet? Perhaps. But they are not a car; they are parts.

It's like you saying that other say you never have to reboot a VMS
system. I never said that. Of course you do if you want to do any
upgrades or AUTOGEN runs. Well, this is my saying.

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

Cryptic and vague.

> (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.  :-)

So? I just opened a .dir;1 file with EDT on a VMS system and nothing
bad happened. I just did again with EVE and still nothing bad
happended! Of course I didn't change the file.

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

Then they're not files.

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

How is accessing one byte at a time make it a file? What's your
defintion of a file? Just what does "everything is just a file"
supposed to mean if I have to write these stupid utilities? How can
any of these things NOT be done on other OSes (Windows and OS X, and
possibly some IBM OSes excluded!). What exactly is the advantage of
Unix when someone says "everything is just a file"? If a super block
were "just a file" I wouldn't have to write no stiking utilities to
find and read it. (Okay, I forgot the "just" part in my original
statement. My apologies. But I think we all knew it was there. At
least I've always heard in the sense that it makes this easier or
better somehow.) As I just parenthed, I've always taken this statement
as to mean that somehow it makes life better in some way. All it seems
to mean is that I have to waste a lot of time to treat some things as
"files" that I wouldn't have to do in at least one other OS.)

So I can access bytes and bits on an ODS-2 disk, too. So what? What's
different? The difference is that in VMS I don't have to write no
stikin' utilities.

I just want to know in what sense super blocks and inodes are files.
Manually hunting them down makes them non-files in my book. You can
use file commands on files! You can't do this for inodes or the super
blocks! If you can't use file commands, how are these creatures files?
They're just a structered set of bits hiding on the disk -- outside
the file system in a sense! -- like a needle in a haystack.

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

AEF