Conference turris::digital_unix

	It is very likely that a disk with a Digital UNIX root file
	system on it will be labeled.  This may not be true for other
	file systems and data.  If the disk is labeled it is very
	likely that the first 32 bit field of the label is the magic
	number for the label.  The data structure of the label is
	described in /usr/include/sys/disklabel.h.

	For non-labeled UFS, it should be sufficient to check the magic
	number in the superblock, which is the 2nd 8 KB chunk of space
	on the disk.

Okay, I see the magic number 0x82564557 64 bytes into the first sector on the
disk.  

Will this number always be the same, and always start at the 64th byte?

Ken

	Look through the disklabel.h include file to see if you
	can find a constant that plausibly corresponds to the
	64 byte offset.  Once you know where the offset comes
	from, it will be easier to determine just how static it
	is.  The magic number is unlikely to change, unless the
	format of the label changes significantly.

I think the 64 byte offset is based on skipping over the old
ULTRIX partition table.  If so, it is pretty unlikely that
the old ULTRIX partition table will EVER change!  My guess
would be a 0.0% chance of change!

	The ULTRIX partition table lived at the end of the super-
	block.

    Is there another way of handling this, using NT's built in facilities ?
    
    If you run NT Disk Administrator, it offers to "write a signature" on
    all the disks it sees. Any you don't write a signature on become
    invisible to ordinary NT apps. DiskAdmin doesn't stop you inadvertently
    "writing a signature" to UFS or Files11 or anything it doesn't
    recognise, and if you do "write a signature" to UFS (and presumably
    AdvFS etc) or Files11, your data is no longer available next time you
    boot the alternate OS. Many people including me know this only too well
    :-(
    
    So if you check for the NT administrator disk signature, you know it is
    an NT disk (FAT, NTFS, whatever) and can safely access it, and you
    already know that Disk Admin has locked out inadvertent disk access to
    the Unix stuff.
    
    Even more simply, why not check the disk under test for FAT or NTFS
    signatures, which are documented in the MSDN Knowledge Base ? That way,
    you don't even need to risk someone making a mistake with DiskAdmin. Or
    is there something I've missed ?
    
    regards
    john

Thanks for the replies.

The "magic number" method worked perfectly.  

re: .4

I'm glad you think there's a 0.0% chance of change.  Reading the comment
section in disklabel.h right before the magic number and offset are defined,
it says:

                   "The stuff below is totally a crock. To start, 
                    it assumes that the label is in the same
                    location on all disks which is bogus, and that 
                    the position of the label is invariant
                    with sector size which is also bogus. For instance, 
                    here at Apollo, we must have it
                    at either 1kbytes from the beginning of the disk 
                    or at 12k from the beginning regardless
                    of the sector size. So I'm just gonna change
                    offset and hold the sector constant."

It doesn't sound like the the chances are 0% to me, but if it changes,
someone else can worry about it when the time comes  :')

re: .6

>Even more simply, why not check the disk under test for FAT or NTFS signatures

That would work except that I want the disk to be write-tested if it has no
filesystem on it at all.

Thanks again,

ken

All that disklabel stuff is DIGITAL specific; the Magic number,
the contents of the header, all of it.  The stuff right before
the magic number is even ULTRIX specific (and that is what I
said wouldn't change).  ULTRIX is in maintenance mode, and we've
even already announced when support will be terminated.  So,
it's not likely we'll change anything there.

As for the comment, if you want to support the finding of Apollo
or Sun, or HP disks, then you've got a whole ton of other research
to do.  Each vendor is free to do that stuff pretty much however
they want.  All that is guaranteed to be correct in that file is
the Digital stuff.

	Fred Knight

>All that is guaranteed to be correct in that file is
>the Digital stuff.

Okay, that's all I'm concerned with.

Thanks again,

Ken