[Info-vax] Request description of UFS for VMS person
AEF
spamsink2001 at yahoo.com
Thu Apr 30 21:18:39 EDT 2009
On Apr 30, 4:35 pm, "Bob Eager" <rd... at spamcop.net> wrote:
> On Thu, 30 Apr 2009 20:15:33 UTC, AEF <spamsink2... at yahoo.com> wrote:
> > On Apr 30, 3:05 pm, "Bob Eager" <rd... at spamcop.net> wrote:
> > > On Thu, 30 Apr 2009 18:21:29 UTC, AEF <spamsink2... at yahoo.com> wrote:
> > > > 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.
>
> > > You're getting hung up on this phrase, which was just a shorthand for
> > > "everything in UNIX can be accessed by file I/O operations".
>
> > I've never heard that. And if so, so what?
>
> Just saying, you're hung up on this phrase. But then you're intent on
> X-knocking, whenever X is not VMS.
No. There are things I like about Unix: Pipe. Output being useful as
input for another program. Try using the output of SHOW QUEUE/FULL/ALL/
SUM as input for SET QUEUE, for example. Why would you want this? To
take a quick snapshot of your queues to create a DCL command procedure
with which you could easily re-create it. Yeah, you should have this
in your startup procedures, but things get lost, you inheret a system
without it, etc. That's what I like about Joe Meadows' FILE utilit as
its output is formatted as to be used directly as input. There are
certainly things I don't like.
There are things I like about MS-DOS even! I like it's F8. That should
be part of every suite of RECALL commands. VMS is close, but I have
yet to find the same in Unix and still have a chance to edit the
command before it's run. Why does it run it right away? Give me a
chance to edit it! Run it immeidately for what: to save one press of
the Return key? Please.
The only thing I was knocking was "Everything in Unix is just a file"
spiel. I've heard that more than once and AFAICT it just isn't true.
As a separate question I asked about how to read the contents of a
super block or inode. OK, you did a super block below. What is
'ad4s1a'? So you've dispensed with the read question for super blocks,
but not for inodes. I think Linux can read them, formatted though,
which is much better than nothing. OK, I conceed that your can read
them, but that doesn't make them files!
> > > So, to use 'od' on the superblock in my FreeBSD system:
>
> > > dd if=/dev/ad4s1a skip=65536 count=1
>
> > If it were a file, I wouldn't need to do this.
>
> Agreed. But so what? I have demonstrated that you don't need to write a
> utility, and now you're moving the goalposts.
No, you only answered the read question. The file question remains:
How is this a file?
Part of the problem is that we need to agree upon just what exactly
constitutes a file. I offer that one should be able to use file
commands, at least 'ls -l'. You can do that with /dev/null. I think
you can even do it with disks. But you can't do it with inodes or
super blocks. OK, you can read them, but they're not files and you
can't read them as files and you can't use any file commands on them.
You have to know some arcane details and come up with strange commands
or write your own utilities.
> > > and pipe it into 'od' (I didn't show that as this newsreader is refusing
> > > to do the pipe symbol)
>
> > > Of, course, that's just one superblock; there are usually many copies.
>
> > > > I just want to know in what sense super blocks and inodes are files.
>
> > > Not sure where you got the original quote from anyway. It's a loose way
> > > of saying that all I/O is via files. OK< you may think it's a
> > > shortcoming that bits of disk data structures aren't available directly
> > > as their own files (they are available as parts of files, though). But
>
> > Then they're not files. (What disk strucutres are available as "part
> > of files", and what's the point? Are super blocks and inodes parts of
> > files?) I can use file commands on files: cp, rm, mv, etc. I can't use
> > these on super blocks or inodes. Therefore, super blocks or inodes are
> > not files. I never heard "file I/O operations". I heard files.
>
> Then you had insufficjent comprehension of what was said.
About what, the "loose way"? It's always said as if it's some
wonderful thing and I've presented reasons as to why it isn't. OK, you
don't really need to do these things very often, but the quote was
everything. And I just want to inspect these things so I could better
understand UFS. I did that same for VMS and for that it was much
easier. I didn't have to write any utilities. Everything I needed was
in DCL.
Another thing: I have, at times, had great difficuly expressing a
question or making a point in this newsgroup. It may well be my fault,
but that's beside the point.
Example 1: It was enormously difficult to explain that EDT's SET
NOTRUNCATE has no equivalent in EVE. People said, "Well, just use
Shift Left and Shift Right." No, that's not the same thing. EVE people
say, "I can look at two files in the same session". Then I say I can
do that with EDT. Then they say I have to keep switching back and
forth between the two buffers. AHA! With EVE you have to keep going
left, right, left, right. Is that any better? Having such a function
in EVE could have saved me a lot of time and grief when I was writing
DCL to export data from a database. EDT's records are limited to 255
chars (mine were much longer), and EVE can't do it. You have no idea
how hard it was to get this point across until I came up with what I
wrote here. No, I didn't and still don't have DECwindows and certainly
wouldn't want to go through that much trouble just for this. I doubt
any boss would buy it for me, anyway.
Example 2: Then there was the time I wanted a timestamp in the DCL
prompt. I wanted the time that the DCL prompt appeared on the screen
to be presented in the prompt so I could read a session log and have
some idea of what happened when. People kept suggesting things I
didn't want. They showed me how to put a live clock there are
something like that. There are plenty of clocks. I tried to say that I
wanted to look back at a log of a terminal session and by inspecting
the prompts I could at least get some idea of when things ran. I just
wanted the time that the prompt appeared to be in the prompt. I think
I finally made headway when I said that MS-DOS (MS-DOS!) does exactly
what I want when you use $D $T in a prompt command. Someone suggested
writing a command file, which was at least on the right track, but
then it screws up the RECALL buffer and possibly also ^Y and ^C.
Finally VAXMAN was kind enough to show me how to do it using his
SYMBOL utility.
These communication problems could well have been my fault. But the
point here is that I may well have not expressed myself clearly or
have been misunderstood or a combination of both. Some people here
seem to be implying that if you can find a way to read it, it's "just
a file". I disagree. You can use file commands on files. You can't do
that with inodes and super blocks. OK, that's that arcane dd command
you came up with. I don't know where that comes from. I'm certainly
not going to stumble upon that as a beginner! And writing utilities?
Sure, one could do that, but to me that means it's not a file.
>
> > > Different doesn't mean bad. Live with it.
>
> > I never said either OS was better or worse. I was just saying that not
> > everything is a file in Unix. On an ODS-2 disk, everything is a file
> > and all the file commands pretty much work the same way on all the
> > files. In particular, you can DUMP any file. I never have to invoke
> > strange dd commands or write utilities. Everything on the disk really
> > *is* a file.
>
> How would you dump the file header for the file with file ID (2341,0,0),
> for example? Without using a special utility? And not dumping all the
> others?
Easy. The trick is to use the DUMP/ID=<number> with the name of an
existing file, even if it's the wrong one! Yes, I admit this wasn't
immediately obvious at first and took a little effort, but certainly
not as much as it would take for me to come up with that arcane dd
command and certainly far less than looking up strange specs and
writing code. But keep in mind a file header is not a file; it is a
block in a file. OK, blocks are not files, but they're part of files.
But that's the same as in Unix, so I'm fine with that. And I never
asked how to just read one part of any of these files. I was happy to
od a directory on an older version of Unix so I could verify that it's
just a mapping of file names to inode numbers. But I found some bytes
in between the pairs and I don't know what they are. Can you tell me
what they are?
Anyway, what you ask here is very easy:
Here goes:
$ DIRECTORY LOGIN.COM; /FILE
Directory DISK$DATA1:[FELDMAN]
LOGIN.COM;85 (36794,5,0)
Total of 1 file.
$
$ DUMP /ID=36794 /HEADER /BLOCK=COUNT=0 LOGIN.COM
Dump of file _DSA1:[FELDMAN]LOGIN.COM;85 on 1-MAY-2009 00:50:41.54
File ID (36794,5,0) End of file block 2 / Allocated 4
File Header
Header area
Identification area offset: 40
Map area offset: 100
Access control area offset: 255
Reserved area offset: 255
Extension segment number: 0
Structure level and version: 2, 1
File identification: (36794,5,0)
Extension file identification: (0,0,0)
VAX-11 RMS attributes
Record type: Variable
File organization: Sequential
Record attributes: Implied carriage control
Record size: 68
Highest block: 4
End of file block: 2
End of file byte: 84
Bucket size: 0
Fixed control area size: 0
Maximum record size: 255
Default extension size: 0
Global buffer count: 0
Directory version limit: 0
File characteristics: <none specified>
Map area words in use: 2
Access mode: 0
File owner UIC: [FELDMAN]
File protection: S:RWED, O:RWED, G:RE, W:
Back link file identification: (7816,16,0)
Journal control flags: <none specified>
Active recovery units: None
Highest block written: 4
Identification area
File name: LOGIN.COM;85
Revision number: 3
Creation date: 23-MAY-2008 14:25:15.32
Revision date: 1-APR-2009 14:10:38.20
Expiration date: <none specified>
Backup date: 24-APR-2009 23:00:01.51
Map area
Retrieval pointers
Count: 4 LBN: 1614284
Checksum: 48571
$
$ DUMP /ID=36794 /HEADER /BLOCK=COUNT=0 LOGIN.COM/NOFORM
Dump of file _DSA1:[FELDMAN]LOGIN.COM;85 on 1-MAY-2009 00:50:45.73
File ID (36794,5,0) End of file block 2 / Allocated 4
File Header
00020000 00040000 00440202 00000000 00000000 00058FBA 02010000
FFFF6428 (d......º.............D......... 000000
00280048 00020000 00000000 00000000 00000000 00000000 000000FF
00000054 T...........................H.(. 000020
20202020 35383B4D 4F432E4E 49474F4C 00000005 00000000 00000010
1E88FA00 .ú..............LOGIN.COM;85 000040
684A0000 00000000 000000A8 965C18A4 CDAC00A7 A0694828 31470003
20202020 ..G1(Hi.§.¬Í¤.\.".........Jh 000060
20202020 20202020 20202020 20202020 20202020 20202020 202000A8
A8B8DC8E .ܸ"". 000080
20202020 20202020 20202020 20202020 20202020 20202020 20202020
20202020 0000A0
00000000 00000000 00000000 00000000 00000000 A1CC5803 20202020
20202020 .XÌ¡.................... 0000C0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0000E0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000100
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000120
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000140
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000160
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 000180
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001A0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ................................ 0001C0
BDBB0000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 ..............................»½ 0001E0
$
>
> --
> Bob Eager
Please let me know if I have not been clear about something. Thanks
for your efforts and replies.
AEF
More information about the Info-vax
mailing list