Article 16: The Amiga Filesystem, Volumes, Assigns and Handlers 

How AmigaOS Organizes Files and Storage In the previous article, we explored AmigaDOS and the Shell. 

We saw familiar names such as:
DH0:
DF0:
Work:
C:
S:
LIBS:
RAM:
NIL: 

At first glance, all of these names look similar because they end with a colon. But internally they can represent very different things. Some identify physical or logical devices. Some identify mounted volumes. Some are assignments pointing to directories. Others represent special services implemented by handlers. Understanding these differences is essential if we want to understand how the Amiga filesystem really works. 

1. The AmigaDOS Namespace 

One of the most elegant features of AmigaDOS is its flexible namespace. Consider:
DF0:
DH0:
Workbench:
Games:
C:
LIBS:
RAM:
CON:
NIL: 

From the user's point of view, all of them can appear as destinations in a path. 

For example:
DF0:Startup-Sequence or:
Work:Documents/Letter or:
C:Dir 

But these names do not necessarily refer to the same type of object. 

We can roughly divide them into:
DOS names
   |
   +-- Devices
   |
   +-- Volumes
   |
   +-- Assigns
   |
   +-- Special handlers/services 

AmigaDOS provides a unified way to access them. 

2. Device Names 

Let's begin with something familiar:
DF0:

 This traditionally represents the first floppy disk drive. 

Additional drives might appear as:
DF1:
DF2:
DF3: A hard-disk partition might appear as:
DH0:
DH1: 

These are DOS device names. They provide logical access to storage through the DOS environment. But there is an important distinction. 

A name such as:
DF0: 

does not mean that applications manipulate the floppy hardware directly. Several layers may exist underneath. 

3. Device Names Versus Exec Devices 

This can be confusing because AmigaOS also has Exec devices. 

For example:
DF0: is a DOS-level device name. 

But:
trackdisk.device
is an Exec device driver. 

They are not the same thing. 

A simplified relationship is:
DF0:
 |
 v
Filesystem / DOS Handler
 |
 v
trackdisk.device
 |
 v
Floppy hardware 

The filesystem interprets files and directories. trackdisk.device handles lower-level disk operations. The floppy controller hardware ultimately accesses the physical disk. 

4. Why These Layers Matter 

Imagine an application reading:
DF0:Documents/Letter 

The application wants a file. It does not want to think about:
tracks
sectors
disk rotation
DMA
floppy controller registers
directory block structures
Instead it asks AmigaDOS to open a file. 

Conceptually:
Application
     |
     v
dos.library
     |
     v
Filesystem
     |
     v
Device driver
     |
     v
Hardware 

Each layer hides complexity from the one above it. 

5. What Is a Filesystem? 

A disk by itself contains blocks of data. The filesystem gives these blocks structure and meaning. 

It introduces concepts such as: 
files
directories
filenames
file sizes
dates
protection flags
free space
allocated blocks

Conceptually:
Raw disk blocks
       |
       v
    Filesystem
       |
       +-- Directory
       |      |
       |      +-- File A
       |      +-- File B
       |
       +-- Directory
              |
              +-- File C 

Without a filesystem, the operating system would only see storage blocks rather than the familiar files and directories presented to applications. 

6. The Original Amiga Filesystem 

Classic Amiga systems are strongly associated with the Amiga Fast File System, commonly called:
FFS 

Earlier systems also used the Original File System:
OFS 

FFS improved storage efficiency and performance compared with the original filesystem. Over the lifetime of the Amiga, additional filesystem implementations appeared, but the important architectural idea is more general: The filesystem is a software layer between AmigaDOS file operations and the underlying storage device. This separation allows AmigaDOS to support different filesystem implementations. 

7. The Role of a Filesystem Handler 

AmigaDOS commonly uses handlers to implement filesystem functionality. 

A simplified view is:
Application
     |
     v
dos.library
     |
     v
DOS
     |
  messages
     |
     v
Filesystem Handler
     |
     v
Storage Device 

The handler receives requests representing operations such as:
Open a file
Read data
Write data
Create directory
Delete file
Rename file 

It then translates those operations into actions appropriate for its filesystem. 

8. DOS Packets 

Communication with handlers traditionally uses a message-oriented mechanism involving DOS packets. This fits perfectly into the wider AmigaOS architecture. 

Remember what we encountered earlier:
Exec
 |
 +-- Tasks
 +-- Signals
 +-- Messages
 +-- Message Ports

AmigaDOS builds more complex services using these fundamental mechanisms. 

Conceptually:
DOS Process
     |
     | request
     v
DOS Packet
     |
     v
Message Port
     |
     v
Handler Process 

The handler performs the requested operation and returns the result. 

9. Why This Design Is Powerful 

Suppose a program opens:
Work:Image 

From the application's perspective, the important operation is:
Open file 

It does not necessarily need to know which filesystem is involved. The application communicates with AmigaDOS. AmigaDOS communicates with the appropriate handler. This means the application can remain largely independent of the physical storage implementation. 

10. Volumes 

Now we need to distinguish devices from volumes. Imagine inserting a floppy disk labelled:
Games into:
DF0: 

There are now two names involved:
DF0: and:
Games: 

They are not equivalent concepts. DF0: identifies the logical drive. Games: identifies the volume. 

Conceptually:
Drive                  Volume

DF0:  ------------->  Games: Remove the disk and insert another named:
Utilities: and the relationship changes:
DF0:  ------------->  Utilities: The device remained the same. The volume changed. 

11. Why Volume Names Are Useful 

Suppose an application needs data from:
Games: It does not necessarily have to care which physical drive contains the disk. 

Conceptually:
Program needs
Games:
   |
   v
AmigaDOS finds volume
   |
   v
Volume currently in DF1: 

This abstraction was particularly useful in the floppy-based world of the original Amiga. The user could manage disks by meaningful names rather than only by physical drive numbers. 

12. Volume Not Present 

This also explains a familiar Amiga experience. A program may request a volume that is currently unavailable. 

For example:
Please insert volume
Games
in any drive 

The operating system knows the required volume name, but that volume is not currently mounted. The solution is not necessarily: Insert a disk into DF0. Instead it is: Make the requested volume available. This distinction is subtle but important. 

13. Hard-Disk Partitions 

The same concepts apply to hard disks. A partition may have a DOS device name such as:
DH0:
but its volume could be called:
Workbench: 

Therefore:
DH0: and:
Workbench: 

may currently lead to the same filesystem. But they describe it from different perspectives.
DH0:          logical DOS device
Workbench:    mounted volume If the volume is renamed, the device name does not necessarily change. 

14. Assigns 

Now we come to one of the most distinctive features of AmigaDOS:
Assigns An assign creates a logical name that points somewhere else. 

For example:
C: might point to:
Workbench:C while:
LIBS: might point to:
Workbench:Libs 

Conceptually:
C:
 |
 v
Workbench:C 

The application does not have to know the physical location. 

15. Why Assigns Are So Useful 

Suppose a program expects its data at:
MyGame: 

You could create:
Assign MyGame: Work:Games/MyGame 

Now when the program accesses:
MyGame:Graphics AmigaDOS redirects that to something like:
Work:Games/MyGame/Graphics 

The software can therefore use a stable logical name even if its files are moved elsewhere. This is remarkably flexible. 

16. System Assigns 

AmigaOS makes extensive use of standard assigns. 

Typical examples include:
C:
S:
L:
LIBS:
DEVS:
FONTS:
T:
ENV: 

Conceptually, a Workbench installation might look like:
Workbench:
 |
 +-- C
 +-- S
 +-- L
 +-- Libs
 +-- Devs
 +-- Fonts AmigaDOS then creates convenient logical names:
C:      -> Workbench:C
S:      -> Workbench:S
L:      -> Workbench:L
LIBS:   -> Workbench:Libs
DEVS:   -> Workbench:Devs
FONTS:  -> Workbench:Fonts 

This separates the logical system structure from the physical disk layout. 

17. Why This Helps Applications 

Imagine an application needs a library. It can refer to:
LIBS: 

rather than assuming:
DH0:Libs 

That matters because another user's system might be installed on:
DH1: or on a volume named:
System: The logical name remains:
LIBS: 

Therefore software becomes less dependent on a particular disk configuration. 

18. Multiple Assign Locations 

AmigaDOS can go even further. Certain assign configurations can encompass more than one location. 

Conceptually:
LIBS:
 |
 +--> System:Libs
 |
 +--> Work:ExtraLibs 

This allows AmigaDOS to search multiple locations through a common logical name. It is a powerful mechanism for extending the operating environment without forcing everything into one physical directory. 

19. Deferred Assigns 

AmigaDOS also supports sophisticated assignment behaviour where the target does not always have to be immediately available. This was useful in systems involving removable media. Again the fundamental idea is: A logical name does not have to be tightly coupled to one permanent physical location. This philosophy appears repeatedly throughout AmigaOS. 

20. RAM: 

One of the most interesting filesystem-like entities is:
RAM: 

RAM: represents the RAM disk. Files copied there reside in memory. 

For example:
COPY Work:TestFile RAM:

 Conceptually:
Disk
 |
 | COPY
 v
RAM:
 |
 v
System memory 

Because access does not require mechanical disk activity, the RAM disk can be extremely fast. 

21. RAM: Consumes System Memory 

However, RAM storage is not free. If you copy a 500 KB file into the RAM disk, approximately that amount of system memory must ultimately be used to hold the data and filesystem structures. 

On an early Amiga with:
512 KB or:
1 MB of RAM, this mattered enormously. 

The RAM disk therefore exchanges memory capacity for storage speed. And naturally, its normal contents are lost when the machine is switched off. 

22. RAD: 

Classic Amiga users may also encounter:
RAD: 

This represents a different RAM-based storage concept. Unlike the ordinary RAM: disk, a recoverable RAM disk can be configured so that its data may survive a warm reboot as long as memory contents remain intact. This was particularly useful for experimentation and certain boot configurations. Again, AmigaDOS makes this special storage system appear through a familiar DOS name. 

23. NIL: 

Not every DOS name represents storage. Consider:
NIL: Writing data to NIL: simply discards it.

Program
   |
   | output
   v
 NIL:
   |
   X 

There is no disk involved. Yet programs can access it through the DOS namespace. This demonstrates that the namespace represents more than filesystems alone. 

24. CON: 

Similarly:
CON: is associated with console functionality. 

A program may use a console specification such as:
CON:x/y/width/height/title to work with console windows. 

Again:
CON: is not a disk. 

It is a service made accessible through the AmigaDOS environment. 

25. The Namespace as an Abstraction 

This makes the AmigaDOS environment both simple for the user and extremely flexible internally. 

26. Locks 

Instead of Only Path Strings Internally, AmigaDOS frequently uses an important concept known as a:
Lock 

A lock represents an association with a file or directory within the DOS filesystem environment. A program can obtain a lock on a directory and then perform operations relative to it. This is important because programs do not always need to manipulate complete textual pathnames for every operation. 

Conceptually:
Path
 |
 v
DOS
 |
 v
Lock
 |
 v
Filesystem object 

Locks play an important role in AmigaDOS filesystem programming. 

27. The Current Directory and Locks 

When a Shell has a current directory such as:
Work:Documents 

AmigaDOS can maintain the appropriate context internally. 

Then:
TYPE Letter can refer to:
Work:Documents/Letter without requiring the complete path every time. The idea of directory locks helps make this possible. This is another example of AmigaDOS maintaining state for each process. 

28. File Handles 

When an application opens a file, it obtains a file handle. 

Conceptually:
Open()
 |
 v
FileHandle
 |
 +--> Read()
 |
 +--> Write()
 |
 +--> Seek()
 |
 +--> Close() 

The handle represents the open stream. The application does not need to manipulate filesystem blocks directly. It works through the DOS API. 

29. Example: Opening a File 

Suppose an application performs something conceptually similar to:
Open("Work:Documents/Test", MODE_OLDFILE); Underneath, the path needs to be resolved. 

A highly simplified sequence might be:
Application
     |
     v
dos.library
     |
Resolve "Work:"
     |
     v
Find filesystem/handler
     |
     v
Locate Documents/Test
     |
     v
Return file handle 

The application can then use that handle for reading. 

30. File Protection 

Bits Amiga files also have protection attributes. Users may encounter flags representing concepts such as:
R   Read
W   Write
E   Execute
D   Delete 

There are also additional protection flags associated with concepts such as:
Script
Pure
Archive
Hold 

These attributes provide information controlling or describing how files should be handled. For example, the script bit can identify a file intended to be executed as a command script. 

31. Files Do Not Need Extensions 

Another important characteristic of classic AmigaOS is that filenames do not fundamentally depend on extensions in the way users of some other systems might expect. 

A command might simply be called:
Dir rather than:
Dir.exe A script might be:
Startup-Sequence rather than:
Startup-Sequence.bat A datatype or application may identify data through other mechanisms rather than relying exclusively on a filename suffix. Extensions certainly can be used, but they are not fundamental to AmigaDOS file execution. 

32. Why This Matters for Amiga Software Installation 

Many classic Amiga programs were installed simply by copying files into several system directories. 

For example:
program       -> Work:Tools/
library       -> LIBS:
device        -> DEVS:
handler       -> L:
configuration -> DEVS: or program directory 

This arrangement makes much more sense once we understand assignments. Software is not necessarily saying: Copy this file to one specific hard-disk partition. Instead it says: Place this library in the system's logical library location. 

That is:
LIBS: 

33. Why Missing Assigns Cause Problems 

Suppose a program expects:
MyProgram: but the assign does not exist. The program may fail to find:
MyProgram:Data even if the data physically exists somewhere on the hard disk. This explains why many classic Amiga programs supplied startup scripts containing commands such as:
Assign MyProgram: Work:Programs/MyProgram Once the assignment exists, the program finds its resources through the expected logical name. 

34. Games and Assigns 

This technique became especially familiar with games. A game originally designed for floppy disks might expect a particular volume or logical name. When installed on a hard disk, an assignment can help reproduce the expected environment. Conceptually:
Game expects:

GameDisk:

But files are actually:

DH1:Games/MyGame/

Assign:

GameDisk: -> DH1:Games/MyGame/ The application can continue using familiar paths without being rewritten for the new storage location. This demonstrates the flexibility of AmigaDOS extremely well. 

35. Booting and the Filesystem 

The filesystem infrastructure also plays an important role during boot. 

Recall the general sequence from our earlier boot article:
Power on
 |
 v
Kickstart
 |
 v
Hardware initialization
 |
 v
Boot device
 |
 v
DOS environment
 |
 v
S:Startup-Sequence
 |
 v
Workbench 

For this to work, the operating system needs to locate the boot medium, access its filesystem and execute the appropriate startup commands. The DOS environment therefore becomes an essential bridge between the low-level boot process and the higher-level Workbench system. 

36. Hard-Disk Filesystems Can Be Modular 

One particularly interesting aspect of Amiga storage architecture is that filesystem code can be treated as a separate system component. Therefore the overall relationship can be:
Disk partition
      |
      v
Filesystem
      |
      v
DOS Handler
      |
      v
AmigaDOS
      |
      v
Applications 

This helped make the Amiga storage architecture extensible. Different filesystem implementations could be introduced without redesigning all applications that use AmigaDOS file operations. 

37. From an Application to the Hardware Let us put the layers together. Imagine an application reading:
Work:Pictures/Amiga.iff 

A simplified path might look like this:
Application
     |
     v
dos.library
     |
     v
Resolve Work:
     |
     v
Filesystem Handler
     |
     v
Filesystem structures
     |
     v
Device driver
     |
     v
Storage controller
     |
     v
Physical storage 

The application only needs to understand:
Open
Read
Close 

The operating system handles the rest. 

38. Why the AmigaDOS Design Is Elegant 

The Amiga storage architecture combines several abstraction mechanisms:
Devices
Volumes
Assigns
Handlers
Filesystems
Locks
File handles 

Each solves a different problem. Devices Identify logical devices. Volumes Identify mounted media or filesystems by name. Assigns Provide location-independent logical paths. Handlers Implement DOS-visible services. Filesystems Organize raw storage into files and directories. Locks Represent filesystem objects and directory contexts. File handles Represent open data streams. Together they form a flexible storage environment. 

39. The Complete Picture 

We can now construct a broader model:
                    Application
                         |
                         v
                     AmigaDOS
                         |
              +----------+----------+
              |          |          |
           Assigns     Volumes    Devices
              |          |          |
              +----------+----------+
                         |
                    DOS Handler
                         |
                     Filesystem
                         |
                    Exec Device
                         |
                      Hardware Special services such as:
RAM:
NIL:
CON: can also participate in the AmigaDOS namespace without representing conventional physical disks. That is what makes the system so flexible. 

40. Why This Still Matters 

Today Understanding this architecture is useful even if your main interest is simply using a classic Amiga. Suddenly many familiar Amiga concepts become logical: Why is a program asking for LIBS:? Why does a game request a disk by volume name? Why can C: point somewhere else? Why does an installation script create assigns? Why is RAM: accessed as though it were a disk? Why are filesystem handlers found in L:? Why are device drivers found in DEVS:? These are all consequences of the same modular design. Conclusion The Amiga filesystem is not simply a collection of disks and directories. AmigaDOS creates a flexible layer of abstraction between applications and storage. 

A name ending with a colon might represent:
a device
a volume
an assign
a filesystem
or a special DOS service Assignments such as:
C:
S:
LIBS:
DEVS: 

allow software to use logical locations instead of hard-coded physical paths. Volumes allow media to be identified independently of the drives containing them. Handlers translate DOS requests into specific services. Filesystems organize raw storage into files and directories. And underneath them, device drivers communicate with the actual hardware. 

A simplified chain looks like:
Application
     |
     v
AmigaDOS
     |
     v
Handler / Filesystem
     |
     v
Device Driver
     |
     v
Hardware 

This architecture demonstrates once again one of the central ideas behind AmigaOS: Separate what the application wants to do from the physical details of how the machine performs it. A program wants to open a file. AmigaDOS determines where that file lives. The filesystem determines where its data is stored. The device driver communicates with the hardware. And the application does not need to know the details. In the next article, Article 17, we can move another level closer to the hardware and explore Interrupts, DMA and Hardware Communication, bringing together the CPU, Exec, Agnus, Paula, Blitter, Copper and the Amiga's bus architecture.