From owner-freebsd-hardware@freebsd.org Tue Sep 26 21:02:05 2017 Return-Path: Delivered-To: freebsd-hardware@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F7A6E2171D for ; Tue, 26 Sep 2017 21:02:05 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mailrelay12.qsc.de (mailrelay12.qsc.de [212.99.163.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.antispameurope.com", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01D1C76171 for ; Tue, 26 Sep 2017 21:02:04 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de ([213.148.129.14]) by mailrelay12.qsc.de; Tue, 26 Sep 2017 23:01:31 +0200 Received: from r56.edvax.de (port-92-195-63-92.dynamic.qsc.de [92.195.63.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id 1F1AA3CC42; Tue, 26 Sep 2017 23:01:29 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id v8QL1TBp002712; Tue, 26 Sep 2017 23:01:29 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Tue, 26 Sep 2017 23:01:29 +0200 From: Polytropon To: Tomasz CEDRO Cc: FreeBSD Questions Mailing List , "freebsd-usb@FreeBSD.org" , freebsd-hardware@freebsd.org Subject: Re: USB Device self-umount Message-Id: <20170926230129.7b00d9a7.freebsd@edvax.de> In-Reply-To: References: <20170926200308.5a9fb785.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-cloud-security-sender: freebsd@edvax.de X-cloud-security-recipient: freebsd-hardware@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mailrelay12.qsc.de with 88B456A3827 X-cloud-security-connect: mx01.qsc.de[213.148.129.14], TLS=1, IP=213.148.129.14 X-cloud-security: scantime:.1473 X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:02:05 -0000 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, ...