Date: Tue, 26 Sep 2017 23:01:29 +0200 From: Polytropon <freebsd@edvax.de> To: Tomasz CEDRO <tomek@cedro.info> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org>, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org>, freebsd-hardware@freebsd.org Subject: Re: USB Device self-umount Message-ID: <20170926230129.7b00d9a7.freebsd@edvax.de> In-Reply-To: <CAFYkXjmMEo13TLyP8cv%2BbmDTz_UfHz%2BeN_FkxJ1hvUFnOfZRRw@mail.gmail.com> References: <CAFYkXjnP7Ha_uZxc1zF0pz_7C3OdsJ3h-H8uyZQE_ViX5=YzBQ@mail.gmail.com> <20170926200308.5a9fb785.freebsd@edvax.de> <CAFYkXjmMEo13TLyP8cv%2BbmDTz_UfHz%2BeN_FkxJ1hvUFnOfZRRw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > device-eject-button-press.. 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. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170926230129.7b00d9a7.freebsd>