Impossible to write changes to ADF floppy images

[Gaula92]

Hi there,

I'm using FS-UAE 2.0.1 and there must be something I'm doing wrong, because I can't keep the changes I make to ADF images I make inside the emulated enviroment.

My configuration looks like this:

# FS-UAE configuration saved by FS-UAE Launcher
# Last saved: 2013-03-06 18:39:54

[config]
amiga_model = A4000/040
chip_memory = 2048
fast_memory = 0
hard_drive_0 = /home/manuel/Desktop/MINIMIG/hardfile_ks3.hdf
hard_drive_1 = /home/manuel/Downloads/moreamiga5
joystick_port_0 = mouse
joystick_port_1 = none
kickstart_file = /home/manuel/Desktop/MINIMIG/Kick31.rom
slow_memory = 1792
writable_floppy_images = 1
zorro_iii_memory = 0

I see it should be working.. it's driving me crazy
When I rename the ADF and load it again, the changes are lost.

[Goingdown]

I think that the changes are not saved on original disks, but to disks under "Save States" folder (Documents/FS-UAE/Save States).

If you rename the disk, you probably must rename the save state dir & file too.

Disclaimer. I haven't tested this.

[Gaula92]

@Goingdown: Thanks!!! That did the trick. I found the modified images there! Thanks for your help

[FrodeSolheim]

Originally Posted by gaula88@hotmail

writable_floppy_images = 1

Hi, i see you have set writable_floppy_images, which will infact modifiy the original ADF file. But this will still not happen when an disk overlay image already exists in the state dir for that ADF file.

If you need to "merge" an ADF with the changes stored in an existing overlay image, you can probably use writable_floppy_images in combination with a new ADF image and perform a disk copy from inside the Amiga. Or you can use an ADF extraction tool from inside the Amiga and save the resulting ADF to a directory hard drive.

[Goingdown]

Frode, I tested this and I cannot get the direct floppy writes to work.

Steps I did:
* created new configuration amiga-test (default a500 config)
* created empty disk test.adf
* added workbench 1.3 and test.adf disks to the amiga-test configuration to disk swaplist
* started fs-uae
* inserted WB disk
* after workbench booted, I inserted test.adf disk
* I renamed test.adf disk (from empty to Test)

Then I stopped fs-uae. And, I can see under ~/Documents/FS-UAE/Save States there is now amiga-test folder, where is file test.adf. I was creating new configuration so I am pretty sure that there was no existing state file.
Original test.adf was not modified

[nexusle]

*** Deleted ***

[Thrash911]

I'm having the exact same problem. Using the latest stable version (v2.0.1) on mac.

This is what I experience, when making changes to a floppy disk.. Per default, it makes an .sdf file in the "Save States" folder, containing disk changes. If I enable "writable_floppy_images = 1", it makes an .adf file in the "Save States" folder.

It never writes to the original .adf file, which is what I also want. Maybe it's a bug?

[Goingdown]

@nexusle: I have set the option. But it does not work

@Thrash911: You are correct, I did see this too... Could it be so that sdf file is "changes to original adf" and if you enable writable_floppy_images, system just copies whole ADF file to Save State...

I will experiment with .adf file in the save state folder - it might be just the modified full adf.

[TCD]

.sdf is indeed an 'overlay' file (changes to the original, not the whole disk image).

[Goingdown]

Originally Posted by TheCyberDruid

.sdf is indeed an 'overlay' file (changes to the original, not the whole disk image).

So, If I enable direct disk writes, it indeed writes the changes to disk, but only saves the resulting changed file to Save States folder, not over the original? Is this intended behavior?

[TCD]

I'm not sure... if the ADF has the changes then I'd say it's the intended behaviour. Have in mind that it is important for netplay to have the exact same disk images So that 'fail safe' way to save them makes sense.

[FrodeSolheim]

Hi, sorry for the late reply here. The original ADF is in fact not modified - when started from FS-UAE Launcher that is.

The FS-UAE option writable_floppy_images itself works as intended, but FS-UAE Launcher additionally copies/extracts ADF files to a temp dir before starting FS-UAE - and saves the file in the state dir if it has changed. I didn't think of this when replying earlier.

Workaround for now - you can move the .adf back from the state dir, overriding the original.

But yes, it is intentional that all changes are saved to the state dir when this is possible and practical, and that original media is left untouched (applies to disk images and directory hard drives in archive formats, but not .hdfs and directory hard drives).

[TCD]

Originally Posted by FrodeSolheim

The FS-UAE option writable_floppy_images itself works as intended, but FS-UAE Launcher additionally copies/extracts ADF files to a temp dir before starting FS-UAE - and saves the file in the state dir if it has changed. I didn't think of this when replying earlier.

That explains the behaviour I experienced when using 'Custom Options'

[Goingdown]

OK, this sounds reasonable. I just did not notice that in first place... And it is actually pretty safe way too.

Is there a way to disable this behaviour? While I see that this is a good and save way to work with floppy images, it can be very annoying if you want to use an adf from different configurations.

[FrodeSolheim]

Hi, I will think on a solution for the Launcher Something like not copying ADF files to the temp dir if "writable_floppy_images" is enabled...

I would just like to mention about this behavior -- it nearly caused me data loss!

I have been tinkering with some amiga programs on winuae, and then installed fs-uae on my mac to continue to work on them on the bus, train, etc. This worked out great in that I could pick up more or less right where I left off by transferring the ADF images right over to the mac via sshfs.

The problem was when I transferred them back.. nothing was there!

Since I didn't know what was happening, I had to search around the internet to find this thread. I created a new configuration that booted a hard drive image with a full version of the OS, (to get diskcopy), disabled floppy overlays, diskcopied the file, manually moved the image back out of the disk overlays dir (grrr) and then transferred the image back to my Linux system, and cleaned up all the needless overlay files.

ONLY !! the data still wasn't there!!

I paniced that I'd lost days of work, but managed to learn how to use the new os x 10.8 continuous versioning junk (I guess it doesn't really delete files when you say to..) to find the overlays and restore them.

You see, when I made a new configuration for booting the hard drive image, it didn't use the same overlay, because the overlays are configuration specfic. Worse than that, they're specific to the current spelling of your configuration. So if you correct a typo, the state goes missing.

This was REALLY not obvious and I had to spend a while looking at paths on the filesystem and scratching my head to figure out what must have gone wrong. I *manually* copied the overlay file to the other configuration, diskcopied again, and got an ADF with my actual data in it, and went on with my life.

My rsync synchronization script now includes a step where it also moves the file back from the disk image dir to where I want it to be.

Takeaways:

* the launcher UI and/or FS UAE UI should probably somehow hint to the user that changes being made are being made to a special hidden directory, not the floppy images being pointed to. This would be helpful for people who want both behaviors.

* If the user is specifically running FS UAE to modify the ADF, it should have a way to just do so.

[FrodeSolheim]

@jrodman You are quite right, and I agree with everything you say The current feature set is more tailored for the game / database / netplay use cases, and less for productivity. As you say, it can be worked around, but there should be a nicer, easier and more obvious way to work with FS-UAE when you want to use disk files in the "traditional way".

I'm thinking about how to solve it in the most elegant and user-friendly way. There are several possibilities, and some solutions are quite simple and obvious.

But it is also somewhat important for the online database and net play features that original floppy images are generally kept (it is also needed for future functionality like rolling back to an earlier state for configurations, etc). One possibility is to implement a copy-on-write system where a copy of the disk image (e.g. an unmodified TOSEC disk) is copied to an "Originals directory" the first time it is written to.

I don't think I'll make any changes in this regard this close to the 2.4.x release, but it is definitively something to consider improving in the 2.5.x series.

EDIT: However, making FS-UAE Launcher respect the existing FS-UAE option writable_floppy_images is a good idea, so it at least is possible to "manually" override the behavior in the cases where the floppy_drive_x (and floppy_image_x) options directly refer to local paths.

[plasmab]

Originally Posted by Goingdown

I think that the changes are not saved on original disks, but to disks under "Save States" folder (Documents/FS-UAE/Save States).

If you rename the disk, you probably must rename the save state dir & file too.

Disclaimer. I haven't tested this.

Thats horrific.. but thanks for the info.

[quantum8]

I just came here as I stumbled across this issue today.

Has there been any thought on implementing something in the GUI?

My suggestion would be 2 checkboxes in the floppy tab:
- writeable; to enable the writable_floppy_images custom option without having to edit a config file
- preserve; defaulting to enabled to keep the current method of using the save states folder. Disable this (possibly with a warning here) to directly access the ADF.