[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