Looks like we are missing a call to
libspectrum_uncompress_file in trdos_disk_insert as gzipped
and bzipped .trd and .scl files are not uncompressed when
inserted.
The problem's actually a bit more complicated than that: the
support for compressed files is essentially for those
formats natively supported by libspectrum (snaps, tapes,
dock cartridges[1]). For +3 disks, libdsk (although not
lib765) provides largely equivalent functionality for
reading gzipped and bzipped disks, so they work there
without any support from libspectrum.
[1] at least now that Fred's patch #884355 provides the
support for dock cartridges.
With the new scheme for 'undoable' writes to disks, we
already create a temporary file for the TR-DOS code to work
with, so it shouldn't be too much work to just uncompress
the image before writing it to the temporary file. There
would remain the question about what to do when we commit
the writes to the disk: do we want the final image
compressed (which is what we get from libdsk) or not? (And
in a related point, what should we do if we have lib765 but
not libdsk?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion the preferable longer term solution is to add support
for disk formats to libspectrum for consistent handling with tapes/
snaps/dcks, and integrating full +3 FDC controller support into
Fuse ala the TR-DOS support.
In the mean time, I guess that the TR-DOS code should try and
match the behaviour of libspectrum (which is to save a new
uncompressed file?).
In the absence of libdsk we should probably try to take the same
approach as the TR-DOS code ends up using. I can't imagine that
there are many Fuse installs with lib765 but without libdsk though,
so perhaps it is also acceptable to just omit support for
compressed +3 disks...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the mean time I'd really like to see libspectrum make
libspectrum_uncompress_file available - after all it realises the file
is compressed, uncompresses it and then discards the results -
leaving the routines that were told the file is a TR-DOS file to
figure out what kind of compression there is and make a
temporary version of their own...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We really should try to fix this. We currently use fopen(), fread(), etc. in disk/disk.c, but I'm not too keen on extending that to include zlib/libbz2 calls, so I suppose we should use utils_read_file() and libspectrum_uncompress_file(), as was originally suggested...
Actually, we'd probably call libspectrum_identify_file_with_class() to determine the file type, which seems to have the side effect of decompressing the file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=11017
The same problem seems to affect Timex dock files.
Logged In: YES
user_id=29214
The problem's actually a bit more complicated than that: the
support for compressed files is essentially for those
formats natively supported by libspectrum (snaps, tapes,
dock cartridges[1]). For +3 disks, libdsk (although not
lib765) provides largely equivalent functionality for
reading gzipped and bzipped disks, so they work there
without any support from libspectrum.
[1] at least now that Fred's patch #884355 provides the
support for dock cartridges.
With the new scheme for 'undoable' writes to disks, we
already create a temporary file for the TR-DOS code to work
with, so it shouldn't be too much work to just uncompress
the image before writing it to the temporary file. There
would remain the question about what to do when we commit
the writes to the disk: do we want the final image
compressed (which is what we get from libdsk) or not? (And
in a related point, what should we do if we have lib765 but
not libdsk?)
Logged In: YES
user_id=11017
In my opinion the preferable longer term solution is to add support
for disk formats to libspectrum for consistent handling with tapes/
snaps/dcks, and integrating full +3 FDC controller support into
Fuse ala the TR-DOS support.
In the mean time, I guess that the TR-DOS code should try and
match the behaviour of libspectrum (which is to save a new
uncompressed file?).
In the absence of libdsk we should probably try to take the same
approach as the TR-DOS code ends up using. I can't imagine that
there are many Fuse installs with lib765 but without libdsk though,
so perhaps it is also acceptable to just omit support for
compressed +3 disks...
Logged In: YES
user_id=11017
In the mean time I'd really like to see libspectrum make
libspectrum_uncompress_file available - after all it realises the file
is compressed, uncompresses it and then discards the results -
leaving the routines that were told the file is a TR-DOS file to
figure out what kind of compression there is and make a
temporary version of their own...
Logged In: YES
user_id=207506
Originator: NO
We really should try to fix this. We currently use fopen(), fread(), etc. in disk/disk.c, but I'm not too keen on extending that to include zlib/libbz2 calls, so I suppose we should use utils_read_file() and libspectrum_uncompress_file(), as was originally suggested...
Actually, we'd probably call libspectrum_identify_file_with_class() to determine the file type, which seems to have the side effect of decompressing the file.