[File] [PATCH] of Magdir/amigaos for Amiga DOS disks *.adf
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Fri Jul 31 21:58:31 UTC 2020
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
some days ago i handled some Amiga DOS disk images with adf file name
extension.
When i run file command version 5.39 with -k option on some samples
like MYadf-1760kFastDirBoot.ADF i get a strange output like:
darknews12.adf: Amiga FFS disk
(Lepton 2.x), scale 1184-5312,
MYadf-1760kFastDirBoot.ADF: data
MYadf1760KBIntl.adf: Amiga Inter DOS disk
(Lepton 3.x), scale 0-0,
MYadfDirImplIntl.adf: data
MYadfFastIntlBoot.adf: Amiga Inter FFS disk
(Lepton 3.x), scale 0-0,
MyHD2MB.adf: Amiga DOS disk
(Lepton 3.x), scale 0-0,
MyHDintl1MB.adf: Amiga Inter DOS disk
(Lepton 3.x), scale 0-0,
testffs.adf: Amiga Fastdir FFS disk
(Lepton 3.x), scale 0-0,
TURBO_SILVER_SV.ADF: Amiga DOS disk
(Lepton 3.x), scale 0-8,
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html).
This recognize all ADF-samples as "Amiga Disk image File (generic)"
by definition file img-adf-ofs.trid.xml.
Furthermore with --extension option only ??? is displayed and with -i
option only generic application/octet-stream is shown.
The file command recognize 6 variants of Amiga DOS disk by lines
inside Magdir/amigaos like
0 string DOS\0 Amiga DOS disk
0 string DOS\1 Amiga FFS disk
0 string DOS\2 Amiga Inter DOS disk
0 string DOS\3 Amiga Inter FFS disk
0 string DOS\4 Amiga Fastdir DOS disk
0 string DOS\5 Amiga Fastdir FFS disk
Some information is found on file format archive team and on
Wikipedia. This is now expressed by comment line like
# URL: http://fileformats.archiveteam.org/wiki/ADF_(Amiga)
# https://en.wikipedia.org/wiki/Amiga_Fast_File_System
The information found on that 2 web sites are some times contradictory.
More details about the ADF format can be found in document
"Amiga filesystem explained" on ADFlib website. This information is
now added by reference URL line like:
# Reference: http://lclevy.free.fr/adflib/adf_info.html
According to Wikipedia there exist two more variants with long file
name support (up to 107 characters instead the usual Amiga limit,
which was 31 characters). That would be expressed by additional lines
like
0 string DOS\6 Amiga long name DOS disk
0 string DOS\7 Amiga long name FFS disk
Because i want to show more informations for ADF images then for
every sub type this routines must be added again and again. So i
rewrite magic test lines. This now becomes like
0 string DOS
>3 ubyte <8 Amiga
By second line similar starting DOS Client Message Files like
IPXODI.MSG DOSRQSTR.MSG are skipped.
Afterwards now show mime type and file name extension according to
web site reposcope.com by new 2 lines like
!:mime application/x-amiga-disk-format
!:ext adf
Afterwards now do sub type classification starting with line like
>>3 ubyte 0 DOS disk
The 2 newer exotic sub types are now shown by 2 lines like:
>>3 ubyte 6 Inter Fastdir DOS disk
>>3 ubyte 7 Inter Fastdir FFS disk
That is what is also identified by TrID as "Amiga Disk image File
(OFS+INTL+DIRC)" and "Amiga Disk image File (FFS+INTL+DIRC)".
The value at offset 3 must be interpreted by bits.
Lowest bit set (or value 1 added) means Fast File System (FFS). If
this bit is not set it is Old File System (OFS).
Value 2 is used when mode (INTL or Inter) is used that allows handle
filenames with international characters those not found in English
(Latin character set).
Value 4 is used for mode with Directory Cache (DC or Fastdir).
If this is enabled, the international mode is also enabled
and the related flag (bit #1) will not be set according to reference.
But software ADFOpus ( See http://adfopus.sourceforge.net ) do set
this bit. So i create my samples MYadfDirImplIntl.adf with value 6
and MYadf-1760kFastDirBoot.ADF with value 7.
According to text on Wikipedia such high values are used for variant
with long name support. Unfortunately i found no such examples. So i
do not know what interpretation of that value is correct. Maybe an
expert of AmigaOS can check this.
For a minimal blank floppy disk the rest of the first block is filled
with zeros. After the stored root block number value the optional
boot block code is stored. So for non bootable disks we find only
null bytes here. For bootable disk we found non nil value here.
By looking for such characteristic machine instructions at that
offset it is possible to identify specific AmigaDOS version like
3.0. If the boot code instructions are not known just show the
hexadecimal sequence. This is now shown by lines like:
>>12 quad !0 \b, bootable
>>>12 ubequad =0x43fa003e70254eae AmigaDOS 3.0
>>>12 default x
>>>>12 ubequad !0x43fa003e70254eae 0x%llx..
I tried to show the file size of ADF images with the new offset
directive by line like:
>>-0 offset x \b, %lld bytes
Unfortunately this only show correct values for low image sizes til 1
MiB limit, that is defined by constant FILE_BYTES_MAX defined in
src/file.h. I also tried to show size for Double Density floppy
images with 880 KiB size by line like
>>-0 offset 901120 (DD 880 KiB)
This message is correctly shown, but following magic lines are not
executed. Maybe this is bug.
So i use a trick to determine image size. According to reference the
the Root block of a partition is normally located in the middle of an
AmigaDOS filesystem. So for Double Density disks this is block 880
and 1760 for High density Floppy discs. So with a block size of 512
just look at that positions for characteristics of root blocks. That
is T_HEADER value 2 at the beginning and characteristic floppy hash
table size value 0x48 for example. So this is done by lines like:
>>0x6E00C ubelong 0x48
>>>0x6E000 ubelong 2 (DD 880 KiB)
>>0xDC00C ubelong 0x48
>>>0xDC000 ubelong 2 (HD 1760 KiB)
Of course there is no guarantee that this always works. But for my
inspected samples it works reliable. Not all adf samples are
described with file size information ( Especially hard disc images
like MyHDintl1MB.adf), but at least i got no false hits.
After the block checksum the root block number is stored. According
to reference this values should be 880 for DD and HD floppies. Often
this is true, but some times this value is zero. I also find cases
like IMAGINE_1_0_DISK_01.ADF or TURBO_SILVER_SV.ADF with high garbage
values like 1146049280. So show non zero values by line like:
>>8 ubelong >0 \b, probably root block %d
Some useful information like volume name is stored inside the root
block. So i introduced sub routine adf-rootblock to show stored
information, especially for unusual values.
At the beginning of root block the block primary type (T_HEADER) is
stored. That value is 2 for root blocks. This is expressed by lines
like:
0 name adf-rootblock
>0x000 ubelong !2 \b, type %u
The next 2 values are header_key and high_seq, which are 0 inside
root blocks. That is shown by lines like:
>0x004 ubelong !0 \b, header_key %u
>0x008 ubelong !0 \b, high_seq %u
Afterwards comes the hash table size ht_size. For floppies this value
is 0x48. That information is shown by line like:
>0x00c ubelong !0x48 \b, hash table size 0x%x
Near the end the volume name length and the volume name string is
stored. If available show this by line:
>0x1B0 pstring >\0 \b, "%s"
Unfortunately the stored root block values in first block is not
reliable. So i use the same trick, that i use for file size
determination. Look for common sizes like 880 or 1760 at expected
block and call sub routine adf-rootblock to show stored information
after checking that inspected block is a root block.
So for 1 MiB hard disc samples like MyHDintl1MB.adf check for
expected T_HEADER value 2 at the beginning followed by zero values
for header_key and high_seq. If this succeeds then i assume it is a
root block and call subroutine adf-rootblock for that block to
display information like volume name. This is done by magic lines like:
>>0x80000 ubelong 2
>>>0x80004 quad 0
>>>>0x80000 use adf-rootblock
After applying the above mentioned modifications by patch
file-5.39-amigaos-adf.diff then i get a more detailed output with -m
Magdir/amigaos option and exotic variants are recognized like:
darknews12.adf: Amiga FFS disk
(DD 880 KiB),
probably root block 880,
bootable AmigaDOS 3.0,
"DARKNEWS #12",
directory cache block 0x371
MYadf-1760kFastDirBoot.ADF: Amiga Inter Fastdir FFS disk
(HD 1760 KiB),
"ADF Opus Created_FastDirBoot",
directory cache block 0x6e1
MYadf1760KBIntl.adf: Amiga Inter DOS disk
(HD 1760 KiB),
probably root block 880,
bootable AmigaDOS 3.0,
"1.76 MB International Mode"
MYadfDirImplIntl.adf: Amiga Inter Fastdir DOS disk
(DD 880 KiB),
probably root block 880,
bootable AmigaDOS 3.0,
"Dir implies Intl Bootable",
directory cache block 0x371
MYadfFastIntlBoot.adf: Amiga Inter FFS disk
(DD 880 KiB),
probably root block 880,
bootable AmigaDOS 3.0,
"Fast Intl Boot"
MyHD2MB.adf: Amiga DOS disk
MyHDintl1MB.adf: Amiga Inter DOS disk,
"HD 1MB inernational Mode"
testffs.adf: Amiga Fastdir FFS disk
(DD 880 KiB),
"ffs_cache",
directory cache block 0x371
TURBO_SILVER_SV.ADF: Amiga DOS disk
(DD 880 KiB),
probably root block 1146049280,
bootable 0x444f5300444f5300..,
"Turbo_Silver-SV"
I hope my diff file can be applied in future version of
file utility.
With best wishes
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCXyST6QAKCRCv8rHJQhrU
1hSLAJ9Ci7KR46hXzgvAjH9lRLmXL0J6qACfVNBMCxEgBH/GfrBqkI7kZkrSUaA=
=TSNf
-----END PGP SIGNATURE-----
-------------- next part --------------
--- file-5.39/magic/Magdir/amigaos.old 2020-05-31 10:34:40 +0000
+++ file-5.39/magic/Magdir/amigaos 2020-07-31 18:32:07 +0000
@@ -50,13 +50,89 @@
# Amiga disk types
+# display information like volume name of root block on Amiga (floppy) disk
+0 name adf-rootblock
+# block primary type = T_HEADER (value 2)
+>0x000 ubelong !2 \b, type %u
+# header_key; unused in rootblock (value 0)
+>0x004 ubelong !0 \b, header_key %u
+# high_seq; unused (value 0)
+>0x008 ubelong !0 \b, high_seq %u
+# ht_size; hash table size; 0x48 for flopies
+>0x00c ubelong !0x48 \b, hash table size 0x%x
+# bm_flag; bitmap flag, -1 means VALID
+>0x138 belong !-1 \b, bitmap flag 0x%x
+# bm_ext; first bitmap extension block (Hard disks only)
+>0x1A0 ubelong !0 \b, bitmap extension block 0x%x
+# name_len; volume name length; diskname[30]; volume name
+>0x1B0 pstring >\0 \b, "%s"
+# first directory cache block for FFS; otherwise 0
+>0x1F8 ubelong !0 \b, directory cache block 0x%x
+# block secondary type = ST_ROOT (value 1)
+>0x1FC ubelong !1 \b, sec_type 0x%x
#
0 string RDSK Rigid Disk Block
>160 string x on %.24s
-0 string DOS\0 Amiga DOS disk
-0 string DOS\1 Amiga FFS disk
-0 string DOS\2 Amiga Inter DOS disk
-0 string DOS\3 Amiga Inter FFS disk
-0 string DOS\4 Amiga Fastdir DOS disk
-0 string DOS\5 Amiga Fastdir FFS disk
+# URL: http://fileformats.archiveteam.org/wiki/ADF_(Amiga)
+# https://en.wikipedia.org/wiki/Amiga_Fast_File_System
+# Reference: http://lclevy.free.fr/adflib/adf_info.html
+# Update: Joerg Jenderek
+# Note: created by ADFOpus.exe
+# and verified by `unadf -l TURBO_SILVER_SV.ADF`
+0 string DOS
+# skip DOS Client Message Files like IPXODI.MSG DOSRQSTR.MSG
+>3 ubyte <8 Amiga
+# https://reposcope.com/mimetype/application/x-amiga-disk-format
+!:mime application/x-amiga-disk-format
+!:ext adf
+>>3 ubyte 0 DOS disk
+>>3 ubyte 1 FFS disk
+>>3 ubyte 2 Inter DOS disk
+>>3 ubyte 3 Inter FFS disk
+# For Fastdir mode the international mode is also enabled,
+>>3 ubyte 4 Fastdir DOS disk
+>>3 ubyte 5 Fastdir FFS dis
+# called by TrID "Amiga Disk image File (OFS+INTL+DIRC)"
+>>3 ubyte 6 Inter Fastdir DOS disk
+# called by TrID "Amiga Disk image File (FFS+INTL+DIRC)"
+>>3 ubyte 7 Inter Fastdir FFS disk
+# but according to Wikipedia variants with long name support
+#>>3 ubyte 6 long name DOS disk
+#>>3 ubyte 7 long name FFS disk
+# DOES NOT only work! Partly for file size ~< FILE_BYTES_MAX=1 MiB defined in ../../src/file.h
+#>>-0 offset x \b, %lld bytes
+# Correct file size, but next lines are NOT executed
+#>>-0 offset 901120 (DD 880 KiB floppy)
+# 880 KiB Double Density floppy disk by characteristic hash table size 0x48 and T_HEADER=2
+>>0x6E00C ubelong 0x48
+>>>0x6E000 ubelong 2 (DD 880 KiB)
+# 1760 KiB High Density floppy disk (1802240 bytes) by characteristic hash table size 0x48
+>>0xDC00C ubelong 0x48
+>>>0xDC000 ubelong 2 (HD 1760 KiB)
+# Chksum; special block checksum like: 0 0x44ccf4c0 0x51f32cac 0xe33d0e7d ...
+#>>4 ubelong x \b, CRC 0x%x
+# Rootblock: 0 880 (often for DD and HD) 1146049280 (IMAGINE_1_0_DISK_01.ADF TURBO_SILVER_SV.ADF)
+>>8 ubelong >0 \b, probably root block %d
+# bootblock code
+>>12 quad !0 \b, bootable
+# assembler instructions: lea exp(pc),a1; moveq 25h,d0; jsr -552(a6)
+>>>12 ubequad =0x43fa003e70254eae AmigaDOS 3.0
+>>>12 default x
+>>>>12 ubequad !0x43fa003e70254eae 0x%llx..
+# 880 KiB Double Density floppy disk (901120 bytes)
+>>0x6E00C ubelong 0x48
+>>>0x6E000 ubelong 2
+>>>>0x6E000 use adf-rootblock
+# 1760 KiB High Density floppy disk (1802240 bytes)
+>>0xDC00C ubelong 0x48
+>>>0xDC000 ubelong 2
+>>>>0xDC000 use adf-rootblock
+# 1 MiB hard disc by test for T_HEADER=2 and header_key=0=high_seq
+>>0x80000 ubelong 2
+>>>0x80004 quad 0
+>>>>0x80000 use adf-rootblock
+# 2 MiB hard disc; only works if in ../../src/file.h FILE_BYTES_MAX is raised to 2 MiB
+#>>0x100000 ubelong x 2 MiB TEST
+#>>0x100000 ubelong 2 \b, 2 MiB hard disc rootblock
+#>>>0x100000 use adf-rootblock
0 string KICK Kickstart disk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.39-amigaos-adf.diff.sig
Type: application/octet-stream
Size: 95 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20200731/cccd8241/attachment.obj>
More information about the File
mailing list