Amiga directory… bomb?

Summary

The other day on pouët, the question came up when people started naming Amiga executable files with an “.exe” suffix, which isn’t really necessary under AmigaOS. Interesting question! I started scanning the disk images I collected for the Amiga Pointer Archive. At least in the TOSEC disk images, .exe files occur as early as 1987, and maybe earlier overall. While the file names scrolled by, I noticed something funny: Endless directory structures that seemed to repeat themselves. Take “3-Demon” from 1988, contained in 3-Demon v1.0 (1988)(Mimetics)[h TBS].adf – an early 3D editor, apparently: This specific disk was spread by The Bitstoppers — they put a README file in front of it, added a little intro… ST-01 samples + coder colors = bliss …and also left their name on the disk as a directory name. When you list the disk contents with AmigaDOS, you get: 1> dir df1: c (dir) objects (dir) devs (dir) s (dir) fonts (dir) libs (dir) ** THE BITSTOPPERS ** (dir) »> BST <« !ReadMe! .info 3-Demon 3-Demon.info BST Disk.info Example 1.3demon However, when you try to list all files recursively with dir df1: all, the system crashes: Click “Cancel” for a guru meditation Neat! Keep those lamers from listing your directories, hehe! But is this a clever file system trick, maybe with a directory containing itself, causing the dir command to exhaust all memory or overflow internal buffers? Kind of like a ZIP bomb – an Amiga directory bomb? At least for this disk, it’s not. If we analyze the ADF image in a file system analyzer like vAmigaDOS, we can follow the directory tree. Amiga OFS file contents are split up in 512-byte blocks, with references to their neighbors, parents, and children. Starting from the root block at 880, we get: [880] 3-Demon: /> block 880 Block : 880 Type : ROOT Header Key : 0 Checksum : 0x19ca146d Name : 3-Demon Created : 18-Mar-88 11:53:49 Modified : 18-Mar-88 11:53:49 Bitmap blocks : 1012 Bitmap extension block : 0 Hash table : 7 -> 883 (.info) 8 -> 925 (c) 10 -> 8...