Fixed missing media change handling

[uweseimet]

[2022-02-21 11:43:59.258] [trace] Received INSERT command
[2022-02-21 11:43:59.259] [info] Validating: operation=INSERT, command params='locale=de', device id=3, unit=0, type=UNDEFINED, device params='file=/home/us/images/transfer.hds', vendor='', product='', revision='', block size=512
[2022-02-21 11:43:59.260] [info] Executing: operation=INSERT, command params='locale=de', device id=3, unit=0, type=UNDEFINED, device params='file=/home/us/images/transfer.hds', vendor='', product='', revision='', block size=512
[2022-02-21 11:43:59.261] [info] Insert file '/home/us/images/transfer.hds' requested into SCRM ID 3, unit 0
[2022-02-21 11:44:03.980] [trace] virtual void SCSIDEV::Selection() Selection Phase ID=3 (with device)
[2022-02-21 11:44:03.980] [trace] virtual void SCSIDEV::Selection() Initiator ID is 7
[2022-02-21 11:44:03.980] [trace] void SCSIDEV::MsgOut() ID 3
[2022-02-21 11:44:03.980] [trace] Message Out Phase
[2022-02-21 11:44:03.980] [trace] void SCSIDEV::MsgOut() ID 3
[2022-02-21 11:44:03.981] [trace] void SCSIDEV::ReceiveBytes()
[2022-02-21 11:44:03.981] [trace] void SCSIDEV::ReceiveBytes() length is 1
[2022-02-21 11:44:03.981] [trace] void SCSIDEV::MsgOut() ID 3
[2022-02-21 11:44:03.981] [trace] void SCSIDEV::ReceiveBytes()
[2022-02-21 11:44:03.981] [trace] void SCSIDEV::ReceiveBytes() ctrl.phase: 10 (msgout)
[2022-02-21 11:44:03.981] [trace] Message code IDENTIFY $80, LUN 0 selected
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() Command Phase
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() CDB[0]=$00
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() CDB[1]=$00
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() CDB[2]=$00
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() CDB[3]=$00
[2022-02-21 11:44:03.982] [trace] virtual void SASIDEV::Command() CDB[4]=$00
[2022-02-21 11:44:03.983] [trace] virtual void SASIDEV::Command() CDB[5]=$00
[2022-02-21 11:44:03.983] [trace] virtual void SCSIDEV::Execute() Execution phase command $00
[2022-02-21 11:44:03.983] [debug] ++++ CMD ++++ virtual void SCSIDEV::Execute() Executing command $00
[2022-02-21 11:44:03.983] [debug] Error status: Sense Key $06, ASC $28, ASCQ $00
[2022-02-21 11:44:03.983] [trace] virtual void SCSIDEV::Error(ERROR_CODES::sense_key, ERROR_CODES::asc, ERROR_CODES::status) Error (to status phase)
[2022-02-21 11:44:03.983] [trace] void SASIDEV::Status() Status phase
[2022-02-21 11:44:03.983] [trace] void SASIDEV::Status() Status Phase $02

[rdmark]

I ran a test on Mac OS 8.6 and patched Apple CD-ROM drivers, just for the record. We've established that Mac OS removable media handling is non-standard, so don't read to much into these results:

• Ejecting an inserted image from RaSCSI leads to the media still appearing as inserted in the Finder.
• It's possible to copy a file off the media to local storage, but the resulting file is invalid. (We know that the Finder keeps a record of volume information in memory)
• Inserting another image from RaSCSI does not lead to the new media appearing in the Finder.
• It's possible to eject the media in the Finder at this point, which leads to the second media being ejected in RaSCSI.
• Inserting a third media in RaSCSI makes it appear correctly in the Finder.
• Mac OS remained stable throughout this. In my previous tests Mac OS used to hang up when trying to access media it thought was still inserted, but this is no longer the case. I'm not certain if these latest code changes affected the behavior (no time to test further right now.)

[uweseimet]

@rdmark Up to now the computer did not have any chance to learn about a media change, because RaSCSI did not report it at all. Now the change is reported as required by the SCSI standard, with the error code reserved for this case. RaSCSI now reports the same as my real SCSI removable media drives do.
I tested this with my Atari, and the Atari drivers now learn about the media change and react accordingly, by essentially discarding any cached data. Removable SCSI media are hot-swappable by definition, this is why it is important that changes are correctly reported. Otherwise the computer may work with stale data and might even write cached data from the previous medium to a new medium, resulting in data corruption.
Removable media drives were/are quite common with Ataris, Atari even distributed such a drive (SyQuest SQ555) themselves (called Megafile 44).

[uweseimet]

@rdmark Why do you think that the Mac's removable media handling is non-standard? The only component that can reliably report a media change is the drive. Any other way to detect a change would mean to constantly poll the drive in order to check whether it is ready or not. (Do the RaSCSI logfiles reflect this?) This kind of polling is very inefficient, as we can see with the Daynaport driver, which is constantly polling for data.

[uweseimet]

@rdmark By the way, there is not just the NOT_READY_TO_READY_CHANGE additional sense code, which is now correctly reported after a medium was inserted, but also the READY_TO_NOT_READY_CHANGE counterpart. I don't think that RaSCSI reports this when a medium is ejected, but the Mac might expect tihis in order for the Finder to do the right thing.
You might want to verify this based on a trace log. If after ejecting a medium the next command, in particular but not necessarily TEST UNIT READY, is not terminated with READY_TO_NOT_READY_CHANGE /but with a different error) there might be another issue with RaSCSI's media change handling.

[rdmark]

@uweseimet I don't see evidence of constant polling in the trace logs either when a disk in inserted, or the emulated drive is empty.
What I do see that looks odd is an absolute deluge of trace and debug log messages when ejecting a CD image from within the Finder (log1.log).
Those logs are not generated when ejecting the disk from the RaSCSI side (log2.log).
I can't really see either of the *_READY_CHANGE messages in either logs.
Does this give you an indicator of anything at all?
log1.log
log2.log

[uweseimet]

@rdmark All those messages actually look like constant polling. TEST UNIT READY is sent all the time. Whether this really makes sense only Apple knows ;-).
When ejecting without using the Finder (by rasctl, for instance) the Finder does not know that the medium was ejected and thus does nothing.