after mounting a .gz-ipped disk image all operations can be performed as on non-compressed disk image file
actual:
saving file to the disk yields no results, when the disk image file is gzipped. Tested on x64.
Discussion
Anonymous
-
2014-01-18
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2014-01-19
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.
Last edit: Anonymous 2014-01-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
if the data can not be permanently written to the disk - error should be returned
if the error is not returned, the data should be permanently stored
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:
a clear warning that disk data is changed and upon quitting the emulator not only RAM data but also DISK changes will be lost
allowing to save the changes to the same disk image or to a new one under new name/location
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
Last edit: Anonymous 2014-01-19
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: