Hard drives

When it comes to using emulated hard drives in FS-UAE, you have several choices:

You can mount directories on your system as Amiga volumes ("directory hard drives").
You can use hard drive images (HDF files).
You can mount zip files as Amiga volumes.
You can in some cases use a real Amiga hard drive / compact flash card.

The best choice depends on how you want to use it. The most convenient is directory hard drives, and I recommend to use this unless you have a good reason not to, especially with FS-UAE v2.1.28+, when support for file permission and metadata was added.

Using directory hard drives

The advantages of using directory hard drives compared with other approaches are:

It will work with all Amiga models, with no Amiga-side setup needed. The volumes (directories) will automatically be accessible from the Amiga.
You’ll have “unlimited” Amiga storage capacity (as long as you have enough free space on your system), and you don’t have to allocate space upfront as you must do with HDFs.
You can also access the files directly from the host system, and you can easily add new files to your Amiga drive from the host system.

Note: You should be somewhat careful about modifying the directory hard drive from the Amiga and from the host system at the same time. Ideally, you should only modify the hard drive from the host system when FS-UAE is not running, since some information about the file system may be cached in the Amiga.

Amiga and host file names

Some file names which are valid on the Amiga are not allowed on the host file system. This is particularly true on Windows, which has one of the most restrictive set of allowed file names (Linux and macOS are more flexible).

FS-UAE handles this by "escaping" the invalid Amiga file names so the can be stored on the local file system. This is only done when necessary, so most file names will not be escaped. Also, the escaping is done so the host file name is valid on all supported FS-UAE platforms.

For example, the following file name is valid on the amiga: Foo\Bar. This is not valid on Windows however, so the file name is escaped and stored as Foo%5cBar. The Amiga will see a file called Foo\Bar when it accesses a directory with a host file called Foo%5cBar. Since Foo\Bar is not allowed on Windows, the file is stored as Foo%5cBar on all platforms. This makes the directory hard drives portable across multiple operating systems.

See also "Extracting Amiga archives" for more relevant information.

Amiga file permissions

When FS-UAE looks up existing files in a directory hard drives, it initializes metadata about the file either from the host file system, or if it exists, from an accompanying metadata file.

When a file has an accompanying metadata file, date/time, file permissions and comment are read from the metadata file. If a metadata file does not exist, then:

The file will get the default permissions: ----rwed.
The file date/time will be read from the last modified timestamp of the host file.
The file will have no file comment.

When files are created/modified from within the Amiga, the host file mtime (last modified time) is updated based on the Amiga file date/time. FS-UAE then decides if it needs to store more information about the file in a metadata file:

If the file has a file comment, FS-UAE will create a metadata file.
If the file has non-default file permissions, FS-UAE will create a metadata file.
FS-UAE reads back the last modified time from the host file, and checks that the time was stored with high enough precision (Amiga files are stored with 1/50s precision). If the time could not be stored accurately, FS-UAE will create a metadata file.
If the file already has a metadata file, FS-UAE will always update the metadata file.

Additional metadata is stored in files with .uaem extension. If the original file is called Image.jpg, the additional metadata is stored in Image.jpg.uaem in the same directory. The metadata is stored in a text format, and you can even edit this file manually from the host side to alter the information about the file. Here’s an example of the content of a metadata file (where "hello" is a file comment):

----rwed 2013-02-12 21:20:52.02 hello

FIXME Format might be outdated, file comments start on the next line now?

Extracting Amiga archives

If you have an .lha archive with Amiga software, you have two choices when you want to extract it:

Extract the .lha archive to the directory hard drive from the host system.
Copy the .lha archive to the a directory hard drive or otherwise make it available to to the virtual Amiga. Start FS-UAE and extract te archive with the lha program (or similar) inside the Amiga.

In many cases, both approaches will work well, but there are some cases where you should extract the archive from inside the emulated Amiga:

If the archive contains Amiga file names which are illegal on the host file system, you’ll not be able to extract the archive correctly on the host system.
The archive can contain file metadata (date/time, file permissions, comment), and if you extract the archive on the host system, information will be lost (the files will get the default file permissions ----rwed).

So whether you can extract an archive without (significant) loss of information on the host system depends on the archive. To be sure, you can always extract archives from inside the Amiga.

Using hard drive images (HDF files)

HDF files are "raw files" containing the content of hard drives, used directly by the Amiga as storage devices (like it would use a real hard drive). This means that the Amiga manages the file system.

There are two common variants of HDF files:

A full HDF image of a hard drive, often referred to as HDF files in RDB (Rigid Disk Block) format. This HDF file must be partitioned, like a real hard drive, before that Amiga can use it.
A HDF file which only contains a single partition. Behind the scenes, FS-UAE will fake a full HDF image with the content of the HDF file as the single partition in the drive.

Using HDF files in RDB format

When you mount a .hdf file as a hard drive in FS-UAE, FS-UAE will automatically recognize it as an RDB file when the HD is already partitioned (the file begins with the RDSK header). If the file is completely empty, FS-UAE will think that it is a partition HDF instead, but you can use the hard_drive_x_type options to force FS-UAE to handle it as an RDB file.

Note: When you use the ADF/HDF creator in FS-UAE Launcher to create a HDF file in RDB format, the file is created in a way that allows FS-UAE to autodetect it as an RDB file.

Empty hard drive images must be partitioned and formatted before use. Workbench may come with a tool called “HDToolBox” which you can use to partition the image. By default, the hard drive is accessed through a HD controller called uaehf.device. You need to tell HDToolBox to use this device when you start it, for example by running the command:

DF0:Tools/HDToolBox uaehf.device

Alternatively, if you emulate an Amiga 600 or Amiga 1200, you can attach the drives to an emulated IDE controller instead (see hard_drive_x_controller). When you use this controller, you can only use hard drive images which are less than 4 GB. The uaehf.device does not have this limitation, so using the default uaehf.device is recommended unless you have a very good reason not to use it. Additionally, uaehf.device is likely more efficient (faster) to use.

After you have partitioned the file, you may need to restart the Amiga. Then you can proceed to format the partition(s).

Using Partition HDF files

When you use an empty partition HDF file, you’ll not partition it – but you still need to format it inside the Amiga before you can use it.

FS-UAE needs to know the geometry of the HDF file. Currently, FS-UAE assumes – and only supports – the default geometry (sectors=32, surfaces=1, reserved=2, block_size=512). There is no option to override this yet. This is compatible with most HDF partition files < 512 MB.

Mounting ZIP archives as hard drives

FS-UAE supports mounting ZIP files as hard drive. This works more or less like a read-only directory hard drive.

Note: There is currently no support for .uaem metadata files in ZIP archives.

When you mount ZIP files and start FS-UAE via FS-UAE Launcher, the ZIP file is handled differently:

The ZIP file is extracted to a temporary directory
This temporary directory is mounted as a directory hard drive in FS-UAE
When FS-UAE is done running, the Launcher scans the temporary directory for changes and saves the changes to the state folder, and when you run the same configuration later, the changed files are merged with the content from the zip file.

Via FS-UAE Launcher, ZIP files work more like a hard drive template, and you get support for metadata files and get a writable file system. The ZIP file itself will remain untouched.

Using real hard drives

Note: This is not an officially supported feature, but it is described here because it works on some platforms. This does not work on MS Windows.

On Unix-like systems, devices can be accessed like files. This means that you can mount a block device (for example a real hard drive or a compact flash (CF) card) as a hard drive, and FS-UAE will use it like it was a HDF file.

You need to make sure FS-UAE have read and write access to the device (you may need to chmod it and/or change device ownership), and also that you use the correct device -you don’t want to overwrite another device by accident.

People have been using this feature on Linux and macOS, but no guarantee is given that it works. The most common use is to mount a CF card which is also used as a hard drive on a real Amiga.

Hard drives

78 thoughts on “Hard drives”

Dom on 2017-06-25 at 20:34 said:

Hi, I’m running FS-UAE on a MacBook. It’s all working well. I’m using a directory hard drive and I can create a file on the Amiga which I can then access on the MacBook via the shared directory.

However, when I copied an ADF file to the directory from the MacBook it was not visible in the Amiga environment.

As I test I made a text file on the Amiga, copied it to the HD and then removed it on the MacBook (the 1 text file was actually 4 files when viewed on the MacBook) and then put it back again and it WAS visible on the Amiga.

Is the problem that the Amiga will only see native Amiga files?

Reply ↓
- FrodeSolheim on 2017-06-25 at 21:12 said:
  
  Hi, it does not matter where the files are created, as such. But Workbench (by default) only shows “icons” (.info files). Some Amiga programs will create both a document and a corresponding .info file when saving.
  
  There is a menu option in Workbench to “Show all files” instead of “Show icons” (or something like that). Enable that to see text files without a corresponding .info icon file.
  
  Reply ↓
Jared on 2017-03-09 at 11:40 said:

I’ve successfully installed Amiga Classic FE in FS-UAE 2.8.3, and hard drive image is RDB file.. and since I know directory hard drives will not work, only image file, how can I share between host and Amiga emulation as it’ just image ? I trying to share Eithnet.lha file from Aminet i’ve downloaded for Network access. Just enableling Network in GUI alone does not help as in FE i still need to point to .device, but the problem is its on the host downloaded,, I just need to share it.. How can this be done with am image?

I tries adding hard drive directory as “secondary hard drive, but OS didn’t boot.. Remove it, and it boots to the OS.

Must i use .zip ? What other options do I have?

Reply ↓
- FrodeSolheim on 2017-03-09 at 17:13 said:
  
  Hi, a good option (until you get networking setup) is to use a second shared HDF/RDB with OFS/FFS. You can then boot a (classic) Workbench config with this HDF mounted – and a directory hard drive, move files from directory to HDF, and then boot AmigaOS 4.1 with this “shared HDF” as a second drive.
  
  Reply ↓
DJ on 2016-10-18 at 21:53 said:

I’m running a game (War in Middle Earth) through WHDLoad with a zipped image and I’m finding that my save games (not states, but the in-game option to save progress) doesn’t survive when I close FS-UAE and run it again. I can load a previously-created save as long as I don’t shut down FS-UAE, but as soon as I close the program, any modified elements of the hard drive seem to be lost. The documentation indicates that these save games should be in the state folder, but I’m having trouble finding that location. I’m sure I’m just making a simple mistake, but so far I haven’t been able to find the solution.

Reply ↓
- FrodeSolheim on 2016-11-05 at 21:12 said:
  
  Hi, some WHDLoad slaves caches changed files until the WHDLoad slave quits. So what happens here is that the savegames are not really saved to disk at all, but exists only in memory. You need to shut down the slave with the correct quit key instead of closing FS-UAE (FS-UAE will close automatically once the slave quits). The WHDLoad splash screen often (always?) informs you what the quit key is.
  
  Reply ↓
  - DJ on 2016-11-17 at 19:59 said:
    
    Thank you! That makes sense, will try it out when I can.
    
    Reply ↓
Garry on 2016-10-18 at 14:11 said:

Can anyone please help me as to how i can have 2x separate “HDF”‘s so i can have 2x hard drives on my emulated A1200 Please ?
I’ve setup my A1200 with 1x “HDF” so far.This i’ve labeled as “System” as it has all the workbench 3.0 discs installed,so the emulator boots into workbench no problem.
Can i create a second “HDF” file so i can install games onto it,using WHDLoad ?
I have tried and tried but when i boot up in my emulated A1200,it’s only showing the “HDF/System” on the screen,even though i’ve loaded the second “HDF/Games” into the second box down in the config.
Any help would be awesome please guys

Reply ↓
- FrodeSolheim on 2016-11-05 at 21:23 said:
  
  Hi! Yes, you can attach multiple .hdf files. There can be several reasons why the Games HDF does not show up. Did you create it as an RDB-type HDF? If so, you need to partition it within Workbench before you will see any drives there.
  
  Reply ↓
- FrodeSolheim on 2016-11-05 at 21:24 said:
  
  Btw, The by far easiest solution is to use directory hard drives. Just create an empty “Games” directory somewhere, and attach it using the folder button for the secondary hard drive.
  
  Reply ↓
Chuck Rose on 2016-03-28 at 07:56 said:

Hello,

In the directions for HDL and RDB files, you mentioned that a hard disk file can be created using fs-uae launcher. I’ve looked all over and I’m embarrassed to say that I couldn’t find it. I am using the Windows version 2.6.2. Could you please direct me to where I can create a hard disk file?

Thanks,

Chuck Rose

Reply ↓
- FrodeSolheim on 2016-03-28 at 13:39 said:
  
  Hi, in the menu in FS-UAE Launcher, there is an entry for “HDF Creator” 🙂
  
  Reply ↓
  - Chuck Rose on 2016-03-29 at 07:57 said:
    
    Thanks, I knew it was in an obvious place, forgot to look in the menu.
    
    Reply ↓
  - Chuck Rose on 2016-03-29 at 18:41 said:
    
    Hmm now workbench 3.1 is refusing to recognize my new hard drive file and refuses to partition what it can’t see in HD toolbox. I’m emulating an A1200, any ideas? I’ve tried every way I can think of: from workbench HDtoolbox, from three different placed on the workbench install disk (including another HDtoolbox that was there. Any help would be wonderful.
    
    More info: The disk I created is mounted as the first drive in the HD section of the launcher, it is 512 MB size, and I specified HD 0 instead of the default 6 because as the website indicates the A1200 hard drive is an IDE and should be 0. When I try to partition the drive, the partitioning program responds “this drive can’t be partitioned and then all other options are grayed out…
    
    Thanks Frode.
    
    Reply ↓
    - FrodeSolheim on 2016-03-29 at 18:44 said:
      
      You need to create an HDF file in RDB mode in order by to able to partition it.
      
      Reply ↓
Gustavo Sarmento on 2015-10-09 at 04:18 said:

Hi,

Directory Hard Drives are not working anymore with the latest stable release on OS X 10.11. Is this a known problem?

Regards

Reply ↓
- FrodeSolheim on 2015-10-14 at 00:10 said:
  
  Not that I know of. Can you send more information? Preferably fs-uae.log.txt.
  
  Reply ↓
  - Gustavo Sarmento on 2015-10-14 at 00:29 said:
    
    There it goes…
    
    fs_uae_configure_hard_drives resolve_path System (relative) checking ./System - found ./System hard drive mount: ./System device: DH0 mount name: System read only: 0 boot priority: 0 set option "filesystem2" to "rw,DH0:System:./System,0" (result: 1) set option "uaehf0" to "dir,rw,DH0:System:./System,0" (result: 1) resolve_path Work (relative) checking ./Work checking /var/folders/5x/q70zp_rs4bn7_h0945z2gb2m0000gn/T/Work checking /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work - found /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work hard drive mount: /Volumes/HD/Users/gustavosarmento/Documents/FS-UAE/Hard Drives/Work
    
    (EDIT:log stripped by Frode)
    
    Reply ↓
    - FrodeSolheim on 2015-10-22 at 21:57 said:
      
      Thanks! The log clearly shows the problem. I have created an option for the upcoming 2.7.4dev which you can use as a workaround. In advanced settings (once you have 2.7.4dev), you can write:
      relative_paths = 0
      
      Explanation of what the option does, and what the problem is: https://github.com/FrodeSolheim/fs-uae/blob/master/doc/options/relative_paths (but short story: FS-UAE gets confused by the /System directory in OS X).
      
      Reply ↓
      - Gustavo Sarmento on 2015-10-25 at 16:45 said:
        
        Thanks a lot! Renaming Amiga’s partitions/directory hard drives to something else also did the trick. 🙂
Niklas Lindholm on 2015-09-27 at 02:30 said:

I have a different timestamp problem that is still present in 2.6.1. I’m running Linux (Ubuntu 14.04LTS) and all my Amiga partitions are directories in the host system. When creating a new file the file timestamp is correct. But when a file is written without being deleted first the timestamp is never updated as the Amiga sees it.

When looking at it from the Linux side it looks like:
Time stamp of actual file: old time
Time stamp of .uaem file: new (correct) time
Time stamp written inside .uaem file: old time

Reply ↓
- FrodeSolheim on 2015-11-09 at 23:36 said:
  
  Hi, thank you for your bug report. I have “moved it” over here https://github.com/FrodeSolheim/fs-uae/issues/94 so I won’t forget to investigate it. If you can, please subscribe to the github bug report!
  
  Reply ↓
  - Niklas Lindholm on 2015-11-10 at 04:49 said:
    
    Subscribed!
    
    Reply ↓
benny on 2015-09-26 at 17:36 said:

I see in the docu here not how can add a amiga drive dh3: that use files from E: \ i use fs-uae win 64 version. on winuae gui i have a stringdad device (here i add dh3:) , on label i can add amiga name. and on path i can add E: \ . but in fs-launcher all this entries miss

Reply ↓
- FrodeSolheim on 2015-09-26 at 19:42 said:
  
  Hi, you can add custom labels for the directory hard drives. There just isn’t any GUI for it yet. What you can do, is to add E: to the *fourth* hard drive entry (that will be dh3: automatically). As for the label, it will be chosen automatically based on the directory name. But to override this, you can go into “Custom configuration”, and enter:
  hard_drive_label_3 = Files (or whatever you want).
  
  -And there will be GUI controls added to tweak this later 🙂
  
  Reply ↓
Fred Wright on 2015-05-23 at 21:36 said:

It behaves the same way on 2.5.30dev. If this bug wasn’t reported before, it’s no surprise that it wasn’t fixed. 🙂

To reproduce:

1) Create a file in an actual Amiga filesystem (e.g., adf or hdf file).

2) Observe the correct timestamp.

3) Copy the file to a “folder-based” file, with the CLONE option.

4) Observe the incorrect timestamp in the result, in both the Amiga view and the host view. In European timezones, this should result in a timestamp in the future.

The new mouse handling seems to be better in some ways and worse in others (better overall), though that probably doesn’t belong in this thread.

Reply ↓
- FrodeSolheim on 2015-05-31 at 15:36 said:
  
  Timestamp bug is confirmed (thank you for listing steps to reproduce!).
  
  Reply ↓
- FrodeSolheim on 2015-05-31 at 16:44 said:
  
  Bug has been fixed for 2.5.31dev: “Fixed a time offset bug in my_utime used by action_set_date”. Thank you for reporting 🙂
  
  Reply ↓
- FrodeSolheim on 2015-06-08 at 22:58 said:
  
  2.5.31dev with the bugfix is out now (for a couple of days), please give it a try 🙂
  
  Reply ↓
  - Fred Wright on 2015-06-09 at 01:52 said:
    
    It works in that version, thanks.
    
    Reply ↓
Fred Wright on 2015-05-22 at 23:07 said:

There seems to be a bug in setting timestamps on “Directory Hard Drive” files. Simple writing of such files sets correct timestamps, but copying them from Amiga files with “Copy CLONE” sets the timestamps incorrectly. In my case, they were set 7 hours early, which corresponds (not coincidentally, I’ll bet) to the difference between PDT and UTC. My guess is that the SetFileDate implementation is treating the supplied Amiga timestamp as UTC rather than local time.

Reply ↓
- Fred Wright on 2015-05-22 at 23:16 said:
  
  Forgot to mention – this is OSX 10.9.5, though I suspect the problem is common to all *nix systems. Not sure about Windows.
  
  Reply ↓
- FrodeSolheim on 2015-05-22 at 23:17 said:
  
  Hi, are you using the latest stable version or the latest development version?
  
  Reply ↓
  - Fred Wright on 2015-05-23 at 01:05 said:
    
    Stable – 2.4.1
    
    Reply ↓
    - FrodeSolheim on 2015-05-23 at 09:05 said:
      
      Could you try to upgrade to the latest development version and report back? I suspect it may have been fixed there.
      
      Reply ↓

Leave a Reply to Chuck Rose Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.