Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#299 +3 disk "save as" option cannot cope with switching disk formats

Brian Ruthven

If I create a blank disk image via "Media -> Disk -> +3 -> Drive A: -> Insert New", I can format it and "CAT" returns "No files found" as expected. If I save it via "Media -> Disk -> +3 -> Drive A: -> Save As..." and specify a name like /tmp/disk (i.e. no .dsk extension) it appears to save a UDI format file.

However, within the emulated +3, "CAT" or any other disk access attempt now returns an error such as "Drive A: track 0, sector 0, no data - RIC?".

It seems that the in-memory copy of the disk image is corrupted, or at least rendered unreadable by fuse. Attempting to format A: also returns "No data".

Now if I re-open that file via "Media -> Disk -> +3 -> Drive A: -> Insert" and select /tmp/disk, I can CAT the file correctly.

My guess would be that fuse switches the file format when saving, and perhaps updates the in-memory format to match. However, it doesn't seem to note the format change, and still tries to access the disk image as if it were the old format. Re-opening the file manually resyncs the file format with fuse's view of the file, and all works again ok.

I'm using fuse 1.1.1 with libspectrum built from source on Solaris 12 (x86). cpmtools is 2.13 with libdsk 1.3.3. All are built from source, and I can supply details if required.


  • Your intuition is quite right. The save-as functionality is a facility that should be transparent to the emulated machine or peripheral. We have had a similar issue with bug [#279]

    In this case, the UDI handling routines compress tracks to save space, but the in-memory copy should remain uncompressed for proper operation. In fact, the opening routine uncompress these tracks. The attached patch should fix that.

    Thanks for reporting this issue.



    Bugs: #279

    • status: open --> pending-fixed
    • assigned_to: Sergio Baldoví
  • Thanks, committed in revision [r5027]. Still pending a rewrite of the disk-image handler, though.



    Commit: [r5027]

    • Group: future --> v1.2