ISO locked by System after unmounting

[cmmc]

Hi,

Mounted a dvd iso with the mds and unmounted it with the eject feature on the tray. Dt drive unmounted ok, but I couldn't move the iso because it was locked by System. Unlocker couldn't detect any lock on the file, but I had to reboot to release it, killing and restarting explorer, logging off/on didn't help. Anything to do with dt?
I'm using Win7 sp1 x64+dt lite 4.41.3.0173

[Terramex]

Technically ejecting in Explorer isn't the same as unmounting.
The virtual disc is still in the virtual tray and therefore still in use by DT.
If you load the virtual tray (e.g. with ImgBurn) you will find the ISO mounted again.

[cmmc]

I checked dt tray app and the unit was unmounted (no media). Also, I ejected it from the tray notifier (green arrow icon), not explorer window, if it changes anything.

[Terramex]

To put it in a nutshell: as long as you don't use the Unmount command (in Tray icon, Gadget or Main Window)
the image will be in use by DT.

[verdy_p]

Actually, even after using the "eject" command in contextual menu of the virtual reader in the Explorer shell, the previously mounted ISO image remains locked in the filesystem by the DT driver itself (Windows reports it as being locked by "System").
To solve this issue, you have to mount another ISO in the same virtual driver, and it will instantly remove the filesystem lock on the previous ISO image, but will install a new lock on the new mounted ISO.

Visibly, DT forgets to close completely the ISO image after it has ejected it, and will do it ONLY if the virtual CD reader is uninstalled (the driver instance will be unloaded along with its used resources on the filesystem).

Workaround: uninstall the virtual drive, or mount another ISO in the same virtual drive if you don't care about having another file locked.

[verdy_p]

ejecting, if this was a true CD/DVD/BD would mean completley remove the disc from the reader tray. You should imply that there's still a CD in the tray, as if it was closed, but should consider it exactly if the CD tray was open for insterting any later media or none. The action of mounting an ISO is equivalent to put a media in the already open tray, and closing the door, so that Windows will start reading it to identify the new media (and display its openal title and icon, and possibly launch the auto-run action).

Please remove the filesystem lock on the ISO file immediately after it has been ejected (because it also forbids us from safely ejecting the media on which the ISO is stored, such as a network drive or an USB drive). You don't need to maintain the filesystem lock, you have just to keep the link to the media in the DT ISO catalog and it's much enough. It is also important to allow defragmenters to defragment the ISO file during maintenance period without having us to reboot the system.

[Terramex]

To solve this issue, you have to mount another ISO in the same virtual driver, and it will instantly remove the filesystem lock on the previous ISO image, but will install a new lock on the new mounted ISO.

No, as already mentioned you just have to use the "unmount" command in DT Tray icon, Gadget or Main Window.
Every virtual drive software acts that way as ejecting is not the same as completely removing the disc.

If you want to automatise the mounting/unmounting you maybe want to have a look at Scripternite:
ScripterNite - Home

[verdy_p]

Clearly this is a constant issue of Daemon Tools. Even when we use the regular "unmount" command, the Windows Tools reveal that the ISO file is locked ONLY by the DT driver and no one else.
The DT driver just forgets to unlobk the ISO file.

In addtion its user interface maintains also a lock on its parent storage directory, because this interface uses it as its "current directory" (in the user local thread n the desktop) when trying to get directory attributes when the last ISO file was mounted. The interface should NEVER set its current directory to the storage area where ISO are found.
This is easy to see: to solve the issue you just need to use a fileselector in the user interface to look for another ISO to add to the Library (you don't need to select one, just navigating with the C:\ root and selecting any non ISO file (that FT will reject as being unsupported) will also be enough to change the current directory.

DT should NEVER set its current working directoty (or only temporarily) elsewhere than on its own application directory (or for the user interface, it may keep the current directory to the home directory of the user profile). IF FT wants to remember the last visited directory, it should not set the current directory but only keep a string for its full path (this is sufficient for allowing to reopen a fileselector from the last visited directory).

There are various Tools available on Windows to determine which process or driver maintains a lock on any file or directory. All of them reveal that DT is at fault.

Please fix these undesrable locks that forbids us to unmount ISO's directly (notably those we have just mounted temporarily, to view its content and extract some file, but that we intend to unmount immediately to delete it from the local desktop where the ISO file was copied temporarily.

Thee locks are even more sever when these ISO's are stored on a remote network directory owned and managed by another user: they require the administrator of the remote storage to reboot to force the removal of these unwanted locks owned by remote users. On a typical network with shard read-only files containing the ISO's we see locks accumulated coming from remote users of DT this should never happen.

Note that shared network folders may be also in a NAS, or on a router: it is not acceptable to have rebooting these servers or routers just to free these unwanted locks created by this bug of DT:

please DT developers, make sure that you NEVER maintain any lock on any file or directory, EXCEPT a read lock on mounted ISO files, and stop changing your "current directory" in your application (on old method inherited from the time of MSDOS programming, which is NOT compliant for getting the Windows conformance label; in Windows, ONLY the cmd.exe program maintains a "current directory", but this lock is dropped as soon as you close the command window, and only one such lock is maintained for all disks, cmd.exe keeps internally a path string for all other disks; the getcwd() API is reprecated and strongly discouraged, you don't need it! Keep your current directory yourself in your own variables, don't use the process context to remember it for you).

[verdy_p]

"unmounting the disk is not the same as removing the disk".

In practice we want that DT "unmounting" does exactly the same thing as "eject disk" (even if we don't remove the disk from a physical tray and the disk remains inside, there's no lock n Windows and the CD/DVD is not visible, before we use some command to see if there's a disk in the tray, by trying to open the drive with the Explorer (in that case it will remount the disk).

In DT, we want that you not only unmount the disk but also eject it. DT should support the full ejection like if it was a regular physical CD/DVD. No need to maintain the ISO locked in the virtual tray, this is just pollution and not needed when DT already offers a Library to select an ISO file to remount later with one click.

[Terramex]

What was the last DT lite version you've tested ?