[Info-vax] ODS-5 data/file recovery

[MG]

On 17-feb-2013 16:19, Hein RMS van den Heuvel wrote:
> Because it is a scary prospect.

True, but it's also a bit of an uneasy situation as I'm still in the
middle of this 'migration'.  So, apart from looking into your code
(thanks again for that), I haven't been able to really look into
the file system internals more.  But, I definitely will though.


> But Marco, it might be as simple as changing one error exit
> to print a warning instead.

That did cross my mind, but I wasn't sure if it was going to be
potentially dangerous.  I will start to try a few things, once I
have 'physically' backed up the volume.


> ODS-5 and ODS-2 are so close that for the purpose of your exercise
> you may well be able to treat them equally. So search for the error
> message and remove the exit following the print, or print instead of
> exit with status.  Not that I think Florian will do much for you. Just
> saying.

Speaking of which: What is your opinion of Florian, is it similar to
DFU?


> I big money was at stake, I would probably use BACK/PHY to an LD device
> such that I could more readily use a file tool (virtual ios: search,
> perl,..) on the image versus a tool that can do logical IOs.

I will do that!


> Mind you DUMP and DCL can access a disk mounted foreign just fine.

I realize that, but since I'm migrating, I'm looking for a way to both
keep the data and be able to shut the system (rx2620) down.  I'll keep
it up for a while, so I will also explore the possibilities with DUMP.

Speaking of which, any things (with regard to DUMP) that you could
recommend me to look into, keep in mind and pay close attention to?


> Out of curiosity I tried patching an ODS-5 marker to ODS-2, but I'm
> afraid to report involves more than one quick update. Maybe folks like
> to see how you can ALMOST do this.
>
> The first structure level indicator is in the home block as byte 12, and
> the block is double-mapped as VBN-2 in INDEXF.SYS so...
> First create a disk to play with:
>
2>
> $ sysman io connect mda2: /noadap /driver=sys$mddriver
> $ init/size=2000 mda2 test /stru=5
> $ moun/sys mda2: test test
> %MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
> $ dism test
> $ init/size=2000 mda2 test /stru=5/clus=7
> $ moun/sys mda2: test test
> %MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
> $ dump/bloc=(coun=1,start=2)/head/wid=80  TEST:[000000]INDEXF.SYS;1
> Map area ...     Retrieval pointers
>          Count:         21        LBN:         35
>          Count:          7        LBN:         91
>
> That "35" (0x023) is critical... is tells us that he homeblock is LBN 36
> (0x024) in this example.
>
> 00070501 0000005B 00000031 00000024  ... 00000
> 0000007D 00000046 001D0016 000F0002  ... 00010
>
> See that "0501" That's ODS-5 version 1
> The 0x24 is pointing back to the block itself,
> as is the 0002 (vbn) on offset 0x10
> The 0x31 is pointing to an (one of many) alternate homeblock as is the 0x0F.
>
> So lets's fix that 0501!
>
> $ moun/for mda2:
> %MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
> $ open/read/write x mda2:
> $ x="abcd" ! 4 byte string
> $ x[0,32]=36 ! Zap in a binary pattern
> $ reca read
> $ read/key=&x x home  ! Must defer interpolation using &, not "'''"
> $ write sys$output f$fao("!XW",F$CVUI(012*8,16,home))
> 0501  ---> structure
> $ write sys$output f$fao("!XW",F$CVUI(510*8,16,home))
> 5E00  ---> checksum
> $ home[012*8,16]=%x0201
> $ checksum = F$CVUI(510*8,16,home) - %x0501 + %x0201
> $  home[510*8,16]=checksum
> $ write sys$output f$fao("!XW",F$CVUI(510*8,16,home))
> 5B00 ---> new checksum
> $ write /upda/symb x home
> $ close x
> $ dism mda2
> $ mount mda2 test test
> %MOUNT-I-MOUNTED, TEST mounted on _RX0$MDA2:
> $ write sys$output f$getdvi("test:","ods5")
> TRUE
>
> Dang!   ... So I went on to patch the first alternate,
> and I patched the structure level in the storage control block
> (offset 0 in VBN 1 of storage bitmap, which is vbn (cluster*4+1) in indexf.sys)
> Still no luck, so I gave up but not after looking for obvious other places:
> $ DUMP/BLOCK=COUNT=1000/OUT=TMP.TMP
> $ SEARCH TMP.TMP "0501 "," 0501",BLOCK
> :
>
> Anyway, I ran out of time on that, but maybe the method is of interest.

Thanks for sharing this!  I'm more and more starting to follow what
is going on.  But, I still have a lot of reading to do.


> The other suggestion i was going to make is made already, but let me echo:
> Make a much similar file as the original and dump,poke and prod that to see
> patterns and to expected picture.

I will do that.


> Steven S might know enough about ZIP files internal to confirm how (im)possible
> your mission is.

That's an excellent idea, I suppose I could contact him.


> For example back to my index file example... each bucket has a VBN sample word,
> which was enough for me to string them together in the right order!

I would have to figure out how to string it back together, but I
needless to say like the sound of that!

  - MG