Cannot properly eject removable media until session which accessed such media has been ended

[Lewis Rosenthal]

Accessing removable media to copy, move, read, write, or simply obtain a directory listing results in that media (whether it is the currently-logged-on-drive or not) not being able to be properly eject from outside the 4OS2 session. Either the ejection request is denied (device in use) or the device is immediately remounted (the latter is the case with the Arca Noae Removable Media Monitor widget).

This behavior has been observed with:

Signature: @#slainc:3.8.-shl#@##1## 2016-10-23 18:34 slamain::::16
7::@@ 4os2 Command Shell Extension - ​http://4os2.netlabs.org/
Vendor: slainc
Revision: 3.08.-shl
Date/Time: 2016-10-23 18:34
Build Machine: slamain
File Version: 3.8.167
Description: 4os2 Command Shell Extension - ​http://4os2.netlabs.org/

and prior. CMD.EXE does not behave like this.

Example:

1. Start 4OS2 & remain logged onto boot volume (e.g., C:)
2. Insert USB media & mount.
3. Run DIR X: (where X: is the drive letter assigned to the new media).
4. Attempt to eject media from CMD.EXE session.

Result:

[C:\]eject x:
SYS0005: Access is denied.

5. Close 4OS2.
6. Repeat step 4.

Result:

[C:\]eject x:

(Device ejects and session returns to a prompt.)

Ejecting from WPS drive object is inconsistent.

Accessing the media from a CMD session and ejecting from a 4OS2 session works consistently, as does ejecting from WPS.

[Steven Levine]

Ticket retargeted after milestone closed

[Lewis Rosenthal]

Apparently, something changed recently, either in USBMSD (most likely) or some other art of the stack. I can no longer reproduce this (FAT32, FAT16, HPFS).

That said, RemM is unable to eject it (device in use), but eject from the CLI works fine. This may be reopened, but we'll see.

[Lewis Rosenthal]

This is indeed reproducible (4OS2 3.09), with both partitioned and unpartitioned media. Copying files to the subject medium, however, does not produce the lock on it, but dir definitely does.