OSFMount not properly handling "unable to read from image" condition

[i3v]

OSFMount seem to not react to sudden inability to read from the disk image file as expected. Actually, it looks like it is not reacting anyhow.
Consider the following experiment:

1. Use Windows Disk Management to create a test 100 MB "P.vhd" file (fixed size, MBR, single partition, NTFS-formatted). Put few files on it.
2. Use Windows Disk Management to create a test 200 MB "Q.vhd" file (fixed size, MBR, single partition, NTFS-formatted). Mount it as "Q:" with Disk Management. Move "P.vhd" to "Q:".
3. Mount "Q:\P.vhd" as "P:" with OSFMount (not-as-RAM-drive, not-as-removable-media, Read-only, Emulation=Logical)
4. Set "Q:" to offline (with Disk Management).
5. Try read some file from "P:". Some files might be cached and they might work like normal. However, eventually, you should run into a "Read error" (as expected).
6. Note that OSFMount window does not highlight the issue anyhow. No error messages or something. This is somewhat misleading.
7. Set "Q:" back to online (with Disk Management).
8. Try read same files from "P:". The files that were cached might still work. However, the files that produced a "Read error" before still produce "Read error". Although now everything seem to be OK and thus this behavior is misleading.
9. In OSFMount try "File->exit" and re-start it. The issue is still present.
10. Dismount "P:" and mount it again. The issue is gone.
11. The mounted "*.img" files seem to behave the same.

Of course, this is just an experiment. A more realistic use case is related to network-shared disk images.


Thus:

• It would be very nice if OSFMount would be able to automatically reopen the disk image file when it is available again.
  • If it's difficult to automate this, maybe it would be possible to provide a single-click "remount" button, at least.
• It would be very nice if OSFMount would highlight "unable to read from image" condition somehow (e.g. additional column with "Status"?)
  • Ideally, a "Total number of 'image file was reopened' since mounted" column would be nice too.

OSFMount v3.1 (1000) on my Windows 10 x64 v1803.

[David (PassMark)]

you should run into a "Read error" (as expected). Note that OSFMount window does not highlight the issue anyhow.

If I understand it correctly, the image file disappeared and OSFMount reported a read error (eventually).
In my mind reporting a read error is highlighting the issue.

There are lots of situations that could lead to a read error. OSFMount isn't going know the difference between a bad disk sector, file corruption, missing image file, hard disk failure, intermittent network failure, CRC error, RAM failure, CPU failure, software bug, device driver bug, SATA cable falling out of the HDD, file permissions changing, etc...
(actually that isn't strictly true, with enough code you can detect some of these conditions, but it is a lot of code for scenarios that should never happen)
Not knowing the exact cause of the problem means that the software doesn't know the best recovery strategy. For most of them there is no path to automated recovery.

But yes, it might be nice to have the same error reported in the UI.

[i3v]

In my mind reporting a read error is highlighting the issue.

It is, but it might be bit difficult to understand what's actually happening if the image file is already back online again - it looks like everything is fine.

I do agree that built-in auto-recovery might be a not very good idea.
But if there would be CLI command to check for "status" (and, more specifically, for "unable to read from image file" condition), one can easily wrap OSFMount with a simple script to check that once in a while and do some "smart" custom recovery.

[David (PassMark)]

Even displaying a status is somewhat problematic. If in a period of 1 second, 10 sector reads are bad and 10 are good, what is the status (assuming the last read was good)?