after mounting a .gz-ipped disk image all operations can be performed as on non-compressed disk image file
saving file to the disk yields no results, when the disk image file is gzipped. Tested on x64.
Compressed images being read only might actually be a feature that is also mentioned in the Manual. Just consider compressed images being archived. If you want to write to an image do not compress it.
Silver Dream !
I am sorry but I strongly disagree. If compressed images are not writable by design - fine. But then this is still not a "manual" problem. In such case this is a problem that non-writable disks do not return 26, WRITE PROTECT ON!
There are few things more bad for the user than a data loss, which is quite probable in current implementation.
Failing with a error 26 is not desirable, as this would break current behaviour which is good in respect to allow software to write to the disk (think of a game with a high score saver). What is missing perhaps is the possibility to save the attached image under a new name which would have two good uses: First current behaviour that preserves your archived (compressed) disk image is retained and second you can save your changed data.
I am not sure if I understand correctly. What I mean is that current behaviour is clearly behaving /differently/ than the machine(s) it emulates. A user who doesn't read the documentation (and who shouldn't have to read it in order to avoid data loss!), knowing very well how CBM machines behave, will never expect that SAVE command, which didn't return an error, in fact didn't save any of his data! For such scenarios as games saving high scores (and not actually saving them) there can be a special "mount/attach" method, similar to what "1541 Ultimate" does and allows. I believe that under no circumstances should user experience data loss due to the emulator trying to care about saving high-scores in some games without saving them. The only situation, in which this could be allowed is when the user does a conscious action and elects to mount ("attach") the disk image in a special way that behaves as described - meaning: different than the real machines. All default behaviour should work the same as real machines behave. Meaning:
Only /special/ behaviour should allow this kind of extra tricks like allowing to "pretend" saving without storing the data as this clearly deviates from how the real CBM machines would behave in the same situation.
Having said that - what you say could be a good workaround to the problem. I'd see as minimum: