[File] [PATCH] Magdir/filesystems for IBM SaveDskF floppy image *.DSK

Christos Zoulas christos at zoulas.com
Mon May 16 13:15:53 UTC 2022


Added, thanks!

christos

> On May 14, 2022, at 5:00 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> some days ago handled files that start with value 0xAA. So i looked
> for other starting with this value. So i looked at some floppy disk
> images with DSK file name extension.
> 
> When running file command version 5.41 on hundreds such examples i
> get an output like:
> 
> 06200B13.DSK: floppy image data (IBM SaveDskF, old)
> 06200D19.DSK: floppy image data (IBM SaveDskF, old)
> 06200D9.DSK:  floppy image data (IBM SaveDskF, old)
> 2-NK.DSK:     floppy image data (IBM SaveDskF)
> 2M256R-K.DSK: floppy image data (IBM SaveDskF, compressed)
> DISK1-2.DSK:  floppy image data (IBM SaveDskF, compressed)
> DISPLAY3.DSK: floppy image data (IBM SaveDskF)
> H1-NK.DSK:    floppy image data (IBM SaveDskF)
> 
> With option -i only generic application/octet-stream is shown. With
> option --extension only 3 byte sequence ??? is shown.
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). Some examples ( like
> 06200D19.DSK 06200D9.DSK 2M256R-K.DS H1-NK.DSK) are not recognized
> and are described as Unknown!. The recognised examples are described
> as "IBM SKF disk image". The examples described by file command with
> an additional "old" are described by TrID with additional "(old)"
> phrase by dsk-skf-old.trid.xml. The examples described by file
> command with an additional "compressed" are described by TrID with
> additional "(comp)" phrase by dsk-skf-comp.trid.xml. The third varian
> t
> examples described by file command without an additional "compressed"
> or "old" are described by TrID with additional "(uncomp)" phrase by
> dsk-skf.trid.xml (See appended trid-v-dsk.txt.gz).
> 
> Luckily TrID tool with option -v shows used file name extension and a
> reference URL. There also links for samples and suitable software are
> listed.
> 
> The detection happens inside Magdir/filesystems by lines like:
> 
> 0	beshort	0xAA58	floppy image data (IBM SaveDskF, old)
> 0	beshort	0xAA59	floppy image data (IBM SaveDskF)
> 0	beshort	0xAA5A	floppy image data (IBM SaveDskF, compressed)
> 
> This now starts like
> # URL:	http://fileformats.archiveteam.org/wiki/LoadDskF/SaveDskF
> # Reference:	http://mark0.net/download/triddefs_xml.7z/
> #		defs/d/dsk-skf-old.trid.xml
> 0	beshort	0xAA58
>> 0	use		SaveDskF
> #		defs/d/dsk-skf.trid.xml
> 0	beshort	0xAA59
>> 0	use		SaveDskF
> #		defs/d/dsk-skf-comp.trid.xml
> 0	beshort	0xAA5A
>> 0	use		SaveDskF
> 0	name			SaveDskF
>> 0	beshort	x		floppy image data (IBM SaveDskF
> !:mime	application/x-ibm-dsk
> !:ext	dsk
>> 1	ubyte		=0x58	\b, old)
>> 1	ubyte		=0x59	\b)
>> 1	ubyte		=0x5A	\b, compressed)
> 
> I put displaying part now inside sub routine SaveDskF. Otherwise i
> must add for all 3 variants part for information giving lines like fo
> r
> file name extension and so on. So i avoid redundance. Furthermore is
> is possible to add more test lines (like check for number of heads)
> when used 2 byte magic reveals as too weak. Instead of generic mime
> type application/octet-stream i choose an user defined one. I myself
> found only example with DSK suffix, but according to documentation
> there should exist samples with digit inside suffix like 1dk, 2dk and
> so on.
> 
> To check for difference between file command and TrID output i
> checked more fields in the header. For debugging and didactic purpose
> you may add some lines like:
> 
>> 38	uleshort	!0	\b, 1st sector at %#x
>>> 1		ubyte	!0x5A
>>>> (38.s)	indirect x	\b; contains
>> 38	uleshort	=0	\b, 1st sector at 0x200
>>> 0x200 indirect	x	\b; contains
> 
> The last field of header at offset 38 contains the offset to first
> sector, which of course is the DOS/MBR boot sector which can it self
> inspected again by Magdir/filesystems via indirect call. This of
> course only works if no compression is used. If this offset is 0,
> then this means real offset value is 0x200, but i do not find such
> examples. Interesting is that many samples although described with
> OEM-ID "IBM 20.0" are described with "dos < 4.0 BootSector (0)". This
> means that the extended boot signature value is not 0x29 as found on
> "new" boot sectors and also not 0x28 as expected for "older" OS/2
> disk. That is not described in the page about the design of the FAT
> file system on Wikipedia. What a surprise!
> 
> On mentioned site download links for examples and tools are
> listed. I verified information partly by 7z package tool (See
> appended  7z-l-dsk.txt) and decoding tool deark (See appended
> deark-l-dsk.txt)  by command lines like:
> 	7z l -tFAT *.DSK
> 	deark -l -m loaddskf  06200D19.DSK
> 
> With the help of this outputs i start to interpret the fields in the
> SaveDskF header. So i should get here the same values as for the
> inspected boot sector and to not confuse the user the same phases
> should be used. But there is one exception. If full capacity of disc
> is not used, the SaveDskF utility does not store unused sectors. It
> stores only used sectors and reports this "lower" counted number
> inside it header part. This i done by additional line like:
>> 34 	uleshort	x	\b, sectors %u
> So for standard 1440 KB samples i get "sectors 2880 (volumes <=32
> MB)" by information of DOS boot sector. For example DISPLAY3.DSK
> i get according to header also this ", sectors 2880," but for smaller
> 06200B13.DSK is get here ", sectors 1017,".
> 
> After the magic bytes the media type is stored as 2 byte integer.
> That is the first byte of the FAT. This value is also stored as byte
> value inside boot sector. That means the upper byte of media type is
> never used. So this seems to be nil in all examples. So now show this
> information by lines like:
>> 2	ubyte		!0xF0	\b, Media descriptor %#x
>> 3	ubyte		!0	\b, upper byte of media type %#x
> For most floppy examples this value is 0xF0, but i also found
> examples with value 0xF9 and 0xFE. The current TrID definition assume
> that this value is always 0xF0. So samples with unusual Media
> descriptors like H1-NK.DSK and 06200D19.DSK are not recognized by
> TrID. If upper byte is always nil then this could also be used as
> additional test which maybe look like:
> 0	beshort	0xAA5A
>> 3	ubyte		=0
>>> 0	use		SaveDskF
> 
> The typical sector size is 512. That value is shown by line like:
>> 4	uleshort	!512	\b, Bytes/sector %u
> There exist discs with other sector sizes, but when i use the
> mentioned SAVEDSKF.EXE tool to create DSK images i got garbage.
> 
> For most floppy examples the number of heads is 2. But i create an
> image H1-NK.DSK with just one head. So show this information for
> unusual case as in the BIOS parameter block by line like:
>> 26	uleshort	!2	\b, heads %u
> As far as i know for floppies or at least standard IBM PC floppies
> here only value 1 or 2 can occur. So this information maybe can be
> used as additional test, which may look like:
>>> 26	uleshort	<3
>>>> 0	use		SaveDskF
> 
> For all inspected floppy examples at offset 30 4 bytes are stored
> with nils. These are described  as unused. So show here unexpected
> values by line like:
>> 30	ulelong		!0	\b, at 0x1E %#x
> If this value is always zero then this could also be used as
> additional test which maybe look like:
>>>> 30	long		=0
>>>>> 0	use		SaveDskF
> 
> For most inspected floppy examples the number of heads is 2. But i
> create an image H1-NK.DSK with just one head. So show this
> information for unusual cases as in the BIOS parameter block by line
> like:
>> 26	uleshort	!2	\b, heads %u
> 
> After the header, an ASCII comment may follow, which seems to be
> terminated by \r\n\0. In all my inspected comment examples the
> comment directly starts after header. That means at offset 40 (or
> hexadecimal 28). In theory the comment could appear later. So the
> offset of the comment string itself is stored at position 36 as 2
> byte value. When following mister Spock logic you would expect that
> for non comment examples this value is something like zero or
> negative. Unfortunately here the value is also 40. So to check for
> the existence of a comment you must check if the first sector (
> That is the DOS boot sector) if far away from the beginning. If
> this not the case (like offset 0x29=41) then there is no space for
> comment.
> Unfortunately there exist samples like 06200B13.DSK, 06200D19.DSK and
> 06200D9.DSK (Seems to concerning "old" variant") where first sector
> is far away (1st sector at 0x200) but the possible comment part is
> just filled with nil bytes. So i must check if possible comment part
> contains printable ASCII or not nil bytes. So now show existing
> comment field by lines like:
>> (36.s)	ubyte		!0x00
>>> 38		uleshort	>41
>>>> 36		uleshort	x	\b, at %#x
>>>> (36.s)	string	x	"%s"
> 
> After applying the above mentioned modifications by patch
> file-5.41-filesystems-dsk.diff then all my inspected DSK examples are
> still described but with more details. This now looks like:
> 
> 06200B13.DSK: floppy image data (IBM SaveDskF, old)
> 	      , 2848 clusters
> 	      , checksum 0xbfa322f2
> 	      , sectors 1017
> 	      , 1st sector at 0x200
> 06200D19.DSK: floppy image data (IBM SaveDskF, old)
> 	      , Media descriptor 0xf9
> 	      , 1st cluster at sector 29, 2372 clusters
> 	      , sectors/FAT 7
> 	      , root directory at sector 15
> 	      , checksum 0xe49f9d51
> 	      , sectors/track 15
> 	      , sectors 1050
> 	      , 1st sector at 0x200
> 06200D9.DSK:  floppy image data (IBM SaveDskF, old)
> 	      , Media descriptor 0xf9
> 	      , 1st cluster at sector 29, 2372 clusters
> 	      , sectors/FAT 7
> 	      , root directory at sector 15
> 	      , checksum 0x70b1daea
> 	      , sectors/track 15
> 	      , sectors 2398
> 	      , 1st sector at 0x200
> 2-NK.DSK:     floppy image data (IBM SaveDskF)
> 	      , Media descriptor 0xf9
> 	      , sectors/cluster 258, cluster shift 1
> 	      , FAT 1, root entries 4096
> 	      , 1st cluster at sector 10, 2876 clusters
> 	      , root directory at sector 10
> 	      , checksum 0x0013ebdd
> 	      , sectors/track 36
> 	      , sectors 12
> 	      , at 0x28 "2880 kb floppy /n /k switch"
> 	      , 1st sector at 0x46
> 2M256R-K.DSK: floppy image data (IBM SaveDskF, compressed)
> 	      , sectors/cluster 258, cluster shift 1
> 	      , reserved sectors 256
> 	      , 1st cluster at sector 288, 2737 clusters
> 	      , root directory at sector 274
> 	      , checksum 0x002614ff
> 	      , sectors/track 36, sectors 290
> 	      , at 0x28 "2880 Kb 256 reeserved sectors"
> 	      , 1st sector at 0x48
> DISK1-2.DSK:  floppy image data (IBM SaveDskF, compressed)
> 	      , 2848 clusters
> 	      , checksum 0x258afca9
> 	      , sectors 287
> 	      , 1st sector at 0x29
> DISPLAY3.DSK: floppy image data (IBM SaveDskF)
> 	      , 2848 clusters
> 	      , checksum 0x18b39069
> 	      , sectors 2880
> 	      , 1st sector at 0x29
> H1-NK.DSK:    floppy image data (IBM SaveDskF)
> 	      , Media descriptor 0xfe
> 	      , root entries 64
> 	      , 1st cluster at sector 7, 314 clusters
> 	      , sectors/FAT 1
> 	      , root directory at sector 3
> 	      , checksum 0x65eac9ab
> 	      , 40 cylinders, heads 1
> 	      , sectors/track 8
> 	      , sectors 304
> 	      , at 0x28 "head 1"
> 	      , 1st sector at 0x31
> 
> 
> I hope my diff file can be applied in future version of file
> utility. So i know that output of file command was and is here
> correct and TrID is wrong in some cases.
> 
> The SAVEDSKF.EXE can create "normal" FAT floppy images (if i remember
> right by /D switch). These are described by file command with
> starting phrase like "DOS/MBR boot sector". Normally such images have
> file name extension like IMG or IMA. The images created by SAVEDSKF
> still use here also the DSK suffix.
> 
> With best wishes,
> Jörg Jenderek
> - --
> Jörg Jenderek
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYoAYegAKCRCv8rHJQhrU
> 1u3mAKCy6ytM7dEvVHsk0+Y5rTseSoiFIgCgvgkrzhUDGUw/UGLD51QsftA9dGw=
> =CqW/
> -----END PGP SIGNATURE-----
> <trid-v-dsk.txt.gz><deark-l-dsk.txt.gz><7z-l-dsk.txt.gz><file-5_41-filesystems-dsk_diff.DEFANGED-0><file-5_41-filesystems-dsk_diff_sig.DEFANGED-1>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220516/31983e9d/attachment.asc>


More information about the File mailing list