On Tue, 26 Sep 2017 22:52:28 +0200, Tomasz CEDRO wrote:
> I will have to see how Windoze handles ATAPI EJECT, maybe that could
> bring some insight on how to umount ejectable media triggered by the
Hmmm... I don't think this is what happens. ATAPI EJECT is issued
by the OS (ATAPI device driver) and the device simply ejects. If
this action is "prefixed" with an unmount() call and a certain
delay, everything is well. This is how a typical GUI file manager
on Linux or FreeBSD works. But pressing the device's eject button
will simply eject the media. Subsequent TUR inquiries by the OS
will result in "device not ready", and that may cause the umount()
call, but _after_ the device has been removed.
> As for now the device reports CHECK-CONDITION to mark media missing,
> then reboots and re-appeares, but that causes "device not cleanly
> unmounted" warnings on macOS for instance..
Of course it does. :-)
With filesystems mounted read-only, this typically isn't a problem,
but those with read-write access might be left in an inconsistent
state, and depending on the OS, cannot be mounted again (or require
a run of fsck, or in case of "Windows", a kind of "repair" that
often leads to data loss and corrupted files).
Examining the USB traffic and checking for the CAM packets exchanged
between the device and the OS could help you find a way to implement
the impossible. ;-)
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"