Opened 8 years ago
Last modified 3 years ago
#37 reopened defect
Cannot properly eject removable media until session which accessed such media has been ended
Reported by: | Lewis Rosenthal | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Version-3.10 |
Component: | Base | Version: | 3.08 |
Keywords: | Cc: |
Description
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:
- Start 4OS2 & remain logged onto boot volume (e.g., C:)
- Insert USB media & mount.
- Run DIR X: (where X: is the drive letter assigned to the new media).
- Attempt to eject media from CMD.EXE session.
Result:
[C:\]eject x:
SYS0005: Access is denied.
- Close 4OS2.
- 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.
Change History (3)
comment:1 by , 6 years ago
Milestone: | Version-3.09 → Version-3.10 |
---|
comment:2 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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).
comment:3 by , 3 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
Ticket retargeted after milestone closed