FrodeSolheim
By default writing to an adf file doesnt write
When i create a new adf disk file and launch it.. if i write to that disk at all it doesnt write to the adf file but instead writes to some obfuscated Documents/FS-UAE/Save States/default/mydisk.sdf
There are 2 horrible issues with this.
- I merrily assume i've updated my adf disk and put it on a USB stick. But my changes arent there.
- Then if i edit my disk and relaunch I never see my edited changes again. ever.
Please remove this feature. At least by default. Its truly horrible.
At the very least could you MD5 sum the input adf before you overrule it with the sdf file and check its really the same file.
That feature is there to protect your dumps from accidental or non expected modification and is well documented.
show a warning then,. its completely unintuitive behaviour. Especially when you try to start a disk with the same name as a disk you've edited and it doesnt work because you're silently getting a disk swapped in place of the one you asked to load!
At least MD5 the source disk before doing this. Its one of the nastiest bugs i've ever seen in any application.
and if i wanted to protect my dumps i'd set the write protection bit on them.
It would be better just to default to read only behaviour.
Also... the claim this is well documented is not supported..
https://fs-uae.net/docs/options/writable-floppy-images
Is an empty page.
There is no mention of this behaviour in the FAQ page or on any of the floppy options pages (or even a link to the behaviour)
https://fs-uae.net/docs/options/floppies-dir https://fs-uae.net/docs/options/floppy-drive-0
There is also no mention of it on this page either.
https://fs-uae.net/docs/getting-started
So please link better to the behaviour because its completely counter intuitive.
I don't think this should be changed. Let's face it, people are lazy and will bitch about their 'ROMs' being 'corrupted' if this didn't happen by default. Documentation is good though.
Please a pop up warning then! And md5 the source disk!!!! You have a bug here when changing the dump file is silently ignored.
On 12 Oct 2018, at 16:38, i30817 [email protected] wrote:
I don't think this should be changed. Let's face it, people are lazy and will bitch about their 'ROMs' being 'corrupted' if this didn't happen by default. Documentation is good though.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I’ll try and spell out the bug because it doesn’t appear to be obvious...
I create dump file called AwesomeGame.adf and boot it.
AwesomeGame.adf actually contains TerribleGame and that game writes something to disk.
I shut down fsuae and move AwesomeGame.adf to TerribleGame.adf...
Now I find the real AwesomeGame.adf and copy it to my dump folder.
When I boot AwesomeGame.adf I get TerribleGame no matter what I do. And I get no warnings.
Sent from my iPhone
On 12 Oct 2018, at 16:38, i30817 [email protected] wrote:
I don't think this should be changed. Let's face it, people are lazy and will bitch about their 'ROMs' being 'corrupted' if this didn't happen by default. Documentation is good though.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
That's.... basically not a bug. If you had TerribleGame and confused it with AwesomeGame that's your own fault for not using a rom renamer with a dat file or similar or using known good sources.
Could it be avoided by fs-uae-launcher checking md5sums and renaming the adfs itself... sure, but fs-uae-launcher is not a rom renamer, inspite of checking (internal) file md5sums.
How do you know if you have just read a disk? So you start fsuae to check. C’mon... it’s awful hidden state.
Sorry but this a total stinker of a bug.
On 12 Oct 2018, at 19:29, i30817 [email protected] wrote:
That's.... basically not a bug. If you had TerribleGame and confused it with AwesomeGame that's your own fault for not using a rom renamer with a dat file or similar.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Or if you, as I did, create a disk with xdftool and make the mistake of writing to it you get stuck for all time with that written disk. A lot of people use fsuae with visual Studio code and Xdftool. We don’t use the gui.
Anyways close the bug since you like having awful hidden state in your app.
On 12 Oct 2018, at 19:29, i30817 [email protected] wrote:
That's.... basically not a bug. If you had TerribleGame and confused it with AwesomeGame that's your own fault for not using a rom renamer with a dat file or similar.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I'm not a contributor, just a user giving his opinion. Chill and wait for the dev.
FS-UAE is targeted for games and netplay. Consistent images are essential. If you have special use cases, you need special options:
If you don't use the gui, just write writable_floppy_images=1 to $CONFIG_DIR/Host.fs-uae and you'll have writable images forever. :-)
I set writable_floppy_images=1 and it is STILL creating overlay files! This nearly caused me dataloss! Plus there doesn't appear to be any way to merge the sdf file with the adf. You should look at how MAME handles this with chd images at the very least, they have a utility called chdman that can merge the changes back into the master image so you can create new images for distribution.
Two and a half year after this has been first reported I'd like to back up the claims that are made here, just to make clear, that this really is a problem and diminishes usability of fs-uae.
- The behaviour is very instransparent. After fiddling around for almost an hour not being able to understand, why the virtual amiga would be able to save and reload something from an adf-image, that only consisted of zeros I dug out the documentation to learn about the hidden sdf saving feature.
- As I only archive my adf files and shared folders this very well might have lead to data loss, had I relied on my adf representing what I actually see in the virtual amiga.
- There is no obvious possibility to remerge the sdf-states back to an ordinary adf files. As I would like to use a virtual amiga to create an adf for writing it back to my real amiga, this is a problem for me.
- From the webpage I found a hint to "use writeable_floppy_images", but adding "writable_floppy_images", "writable_floppy_images = true" and "writable_floppy_images = 1" to the config file only the last one works.
- Entering Config options from the GUI is not on a configuration but on global basis and the GUI claims that this feature will be removed in the future.
=> I think it's a cool feature but it needs to be better depicted in the GUI, it must be clear where data is really saved to, there should be a possibility of remerging and there should be an option in the GUI to switch it off.
These shadow copies are really a horror - whether for harddrives or floppydrives. Even though I knew I could disable this "feature" for harddrives, I still ran into the same(!) problem for floppydrives. I noticed this just now because I made some profound changes in my code that have visual effects on the program. All my previously done performance tests are invalidated by this.
Several years ago I ran into a massive data loss because of this, as I was first working in Linux with FS-UAE and harddiskdrives - where the thing happily made shadow copies for me. After weeks, I wondered why WinUAE was behaving so strangely and not displaying current data. Thanks for nothing!
This feature is just horror, especially since the whole thing is also not properly documented, nor visible on the interface at all. Clueless new users, but also the users who switch from WinUAE, have no chance and running into this pain...
I agree that the functionality is not obvious, because users are not told what is happening. It is a useful feature in many cases, but has been mentioned here, can also cause pain when you're not aware of it. The functionality was good for gaming (at least for the main use case FS-UAE was designed for), but not for productivity. Part of the problem I wanted to solve was using FS-UAE in different configurations (netplay, online game database) where unmodified game images were needed to ensure correct behavior.
I am probably going to change this for FS-UAE 4 somehow. For game configurations from the online game database. This functionality, or something similar, still makes sense. But the default in all other cases should probably we to write back to ADF images. There could be an UI switch for this which defaults to on when using online game configurations and off otherwise.
With FS-UAE Launcher, there are also opportunities to create more high-level functionality to make sure unmodified ADF images for gaming are present. FS-UAE Launcher could make temp copies of the ADF images, so overlay images are not needed to begin with. Or, the Launcher could instruct FS-UAE to make copies of the ADF images before they are written to the first time (e.g. Gamefile.adf -> Gamefile_original.adf, or -> Originals/Gamefile.adf. Something like that). In this case, FS-UAE Launcher could index the newly created original adf files after FS-UAE quits and use these when launching games that need exact SHA1sum matches.
So, in short, I haven't decided exactly how FS-UAE/Launcher 4 will behave in this regard, but I want to make the behavior more intuitive / discoverable by the user.
(FS-UAE does not use overlays for hard drive images btw @Nju79)
Curious, Has anyone discovered a way to merge the sdf into a generic adf ? I just spent a bunch of time playing around in 1.3 workbench reliving the old days. I thought when I created blank adf files and formatted them I would be able to save stuff. It APPEARED to work! Only to find out later that all that stuff is really only saved to sdf files that only load in the 'default' configuration profile.
The first time I created a named configuration profile I no longer can see the modifyied contents. Perhaps if I can get it to load the default, then use the modify original and disk copy to a real adf ? Seems like a pain. I'm not opposed to having the protection, but think the state file should just be a normal adf, or even if it only writes changes, perhaps a convient way to merge it to a new adf even better.
Otherwise I'm not sure its worth it. Nothing I'm using in the emulator is a 'precious' adf file. Unless maybe its a new one I just created, and I'm expecting the emulator to modify it, and expecting to be able to make copies of it in my host os.
@wjkoontz:
I can reply with instructions for a linux system:
Step 1: Enable writable adfs
You can create writable adfs by adding "writable_floppy_images = 1" to the textfield in the "extended" preferences, or by issueing "--writable-floppy-images=1" on the command line.
Test Step 1: After that, newly created adfs should be writable. I usually test it by creating an all-zero file of 901120 Bytes length (Blocksize of Amiga 512 Bytes, 11 Sectors per Track, 80 Tracks per side, 2 sides = 512 Bytes * 1760 Sectors = 901120) , naming it filename1.adf:
dd if=/dev/zero of=filename1.adf bs=512 count=1760
Then I attach it to fs-uae and format it with the workbench.
After formatting you should instantly see something like this, if you invoke an hexeditor like xxd:
xxd filename1.adf | less
00000000: 444f 5300 444f 5301 444f 5302 444f 5303 DOS.DOS.DOS.DOS. 00000010: 444f 5304 444f 5305 444f 5306 444f 5307 DOS.DOS.DOS.DOS. 00000020: 444f 5308 444f 5309 444f 530a 444f 530b DOS.DOS.DOS.DOS. 00000030: 444f 530c 444f 530d 444f 530e 444f 530f DOS.DOS.DOS.DOS. 00000040: 444f 5310 444f 5311 444f 5312 444f 5313 DOS.DOS.DOS.DOS. 00000050: 444f 5314 444f 5315 444f 5316 444f 5317 DOS.DOS.DOS.DOS.
Step 2:
Once a file is in this split-state fs-uae cannot merge it back. Even if you enabled writable adfs a split-adf will stay in split-mode. But you can copy the content of a split-adf to a non-split one using the Amiga.
After you made sure that you really can write to newly created adfs, you can use (preferrably) X-Copy on the amiga side or even workbench diskcopy to copy the content of the split-adf to the writable one.
Test Step 2:
You can use xxd in the same way as above to make sure, that your content is really in the newly created adf file.
Or you can mount the adf with linux, if it contains a standard filesystem:
sudo mount -t affs -o ro,loop some.adf /mnt
Old topic, but I found a bug in this. Using FS_UAE 3.1.68 on Mac and the writable_floppy_images = 1 does not work unless the sdf-file is removed
The documentation regarding this function is pretty much non-existent, and to be honest it is really stupid to implement as default that you can't save to disk (adf-file) and expect the data to be on that disk (adf-file). Seems someone actually forgot what a floppy is actually about. If you want to make a disk write protected fine, do it. But then you should get the same behaviour as with a real floppy.
Aargh... Ineed @MrMesch - thanks for pointing that out.
I also want to add my voice to how frustrating this behaviour is. It's a floppy disk concept, right? it's used to transfer data from one system to another, right?
In FSUAE, you save something to floppy, insert that floppy in another system, and your files are not there... Then you think "ah right, FSUAE has this weird floppy overlay thing going on" You put in the writable_floppy_images = 1 option, repeat your steps and... your files STILL aren't there!
And even if you read the documentation it simple says "FIXME: "Documents/FS-UAE/Floppy Overlays" is no longer the correct path" so you have to hunt for yourself where on earth that overlay file is that overrides everything ...
Please stop treating your users as morons and change this default overlay file behaviour, it makes no sense and mostly causes frustration.
One important addition: the method in https://github.com/FrodeSolheim/fs-uae/issues/186#issuecomment-1104830520 works, but you have to use the same configuration. The reason is, that the overlay SDF files are unique per configuration.
I've created a second configuration for the copy and therefore the SDF was not used. I had to switch back to the original configuration so that the contents of the overlay became visible.
If there were any documentation of this SDF format, I could write a merge tool.
This "feature" and the lack of easy to disable option toggle and poor documentation just cost me 2 weeks of frustration and hair pulling. This is one of the absolute worst features of UAE I've ever heard of. Terrible decision.
