Ipmlab goes ahead, calls Aaru. Results in image with only null bytes.
This ONLY happens while floppy drive is connected via write blocker. Interestingly, the size of the empty image file always seems to correspond to the size of the most recently processed disk. Looks like the write blocker generates an empty buffer based on most recently attached medium, and exposes that to the OS.
It is possible to identify this from the log file created by Aaru, e.g. ???cic.xml lists total number of blocks:
While testing without a write blocker, I noticed that Ipmlab was often unable to detect floppy after 1st attempt at reading with empty floppy drive. Could be virtualisation issue, as when this happened I was also unable to access the drive from the command line (directory listing).
Tested with Windows 10, running in VM.
Expected behavior:
Actual behavior:
This ONLY happens while floppy drive is connected via write blocker. Interestingly, the size of the empty image file always seems to correspond to the size of the most recently processed disk. Looks like the write blocker generates an empty buffer based on most recently attached medium, and exposes that to the OS.
It is possible to identify this from the log file created by Aaru, e.g. ???cic.xml lists total number of blocks:
Then in ???resume.xml:
While testing without a write blocker, I noticed that Ipmlab was often unable to detect floppy after 1st attempt at reading with empty floppy drive. Could be virtualisation issue, as when this happened I was also unable to access the drive from the command line (directory listing).