Wrong drive letter assigned and mounted

[rkrikava]

Environment

• Windows version: Windows 10 x64
• Processor architecture: Intel i5-3470
• Dokany version: 1.0.0 RC4
• Library type (Dokany/FUSE): Dokan

Check List

• I checked my issue doesn't exist yet
• My issue is valid with mirror default sample and not specific to my user-mode driver implementation
• I can always reproduce the issue with the provided description below.
• I have updated Dokany to the latest version (https://github.com/dokan-dev/dokany/releases) and have reboot my computer after.

Description

Every so often dokany will assign drive letter 'M' instead of the specified mount point (In my case "S:"), and mounts the file system on 'M:'. When this bug occurs, the drive 'M' remains after the drive is unmounted. Below I have provided the pertinent sections of the kernel logs.

Logs

01421044 5660.48828125 [DokanFS] ==> DokanDispatchIoControl
01421045 5660.48828125 [DokanFS] ProcessId 10988
01421046 5660.48828125 [DokanFS] IdType = DGL
01421047 5660.48828125 [DokanFS] => DokanGlobalDeviceControl
01421048 5660.48828125 [DokanFS] IOCTL_EVENT_START
01421049 5660.48828125 [DokanFS] ==> DokanEventStart
01421050 5660.48828125 [DokanFS] Using Mount Manager
01421051 5660.48828125 [DokanFS] Checking for MountPoint \DosDevices\S:\
01421052 5660.48828125 [DokanFS] DiskDeviceName: \Device\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9} - SymbolicLinkName: \DosDevices\Global\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9} - MountPoint: \DosDevices\S:
01421053 5660.48828125 [DokanFS] IoCreateDevice DeviceType: 8
01421054 5660.48828125 [DokanFS] SymbolicLink: \DosDevices\Global\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9} -> \Device\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9} created
01421055 5660.48828125 [DokanFS] MountId:23
01421056 5660.48828125 [DokanFS] DeviceName:\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9}

01421945 5660.49414063 [DokanFS] ==> DokanDispatchIoControl
01421946 5660.49414063 [DokanFS] ProcessId 10988
01421947 5660.49414063 [DokanFS] IdType = DCB
01421948 5660.49414063 [DokanFS] => DokanDiskDeviceControl
01421949 5660.49414063 [DokanFS] DiskDeviceControl Device name \Device\Volume{d6cc17c5-1722-4085-bce7-964f1e9f5de9}
01421950 5660.49414063 [DokanFS] IOCTL_MOUNTDEV_LINK_CREATED
01421951 5660.49414063 [DokanFS] MountDev Name: \DosDevices\M:
01421952 5660.49414063 [DokanFS] Mount Point already assigned to the device. New mount point ignored.
01421953 5660.49414063 [DokanFS] <= DokanDiskDeviceControl
01421954 5660.49414063 [DokanFS] status = 0x0
01421955 5660.49414063 [DokanFS] status = STATUS_SUCCESS
01421956 5660.49414063 [DokanFS] status = 0x0
01421957 5660.49414063 [DokanFS] status = STATUS_SUCCESS
01421958 5660.49414063 [DokanFS] <== DokanDispatchIoControl

[Liryna]

Hi @rkrikava,

I have not been able to reproduce the behavior you describe.
Do you an idea how to make this happen with the mirror ?

[rkrikava]

It doesn't happen reliably but I'd say probably 1 in 25 times running the app. I will try to reproduce with the mirror app.

[Liryna]

@rkrikava any news from this ?

[rkrikava]

I haven't been able to reproduce this in the mirror app, yet. I had set up
some automated tests to try to reproduce this in a VM. Its on the
back-burner for now, but I will get back to this soon.

On Tue, Sep 6, 2016 at 4:05 PM, Liryna notifications@github.com wrote:

@rkrikava https://github.com/rkrikava any news from this ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#317 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUEi_B8Ou5aS8TEXtSgQ3AZ1Atark1jGks5qnceXgaJpZM4Jk0kp
.

Roland Krikava
+1 845 419 3729
https://www.linkedin.com/in/rolandkrikava

[rkrikava]

Please find attached a zip containing everything needed to reproduce the bug on a Win10 x64 machine. The README.txt explains the steps necessary. I'm not quite sure why this bug could not be produced in a VM, but on my machine it reliably triggers after about 22 iterations.

MountPointBug.zip

[rkrikava]

Have you been able to reproduce the bug? Let me know if you have any questions.

[Liryna]

@rkrikava sorry didn't had time for it now 😢 busy week

[Liryna]

It seems you are using mount manager option here. Have you try without /o ?
@Maxhy If I remember the mount manager will choose the mount point himself if the the mount point is already used ?

[rkrikava]

I ran the test without '/o' option. Currently at 375th iteration of mouting/umounting, so it looks like this bug is mount manager specific.

@Liryna It seems there is more than one bug:

• Unmount fails to completely unmount 'S:'
• On the next mount request for drive 'S:', DokanMain succeeds and the mount point reported in the callback is 'S:' even though 'M:' is used. The expected behaviour would be for DokainMain to fail, allowing the user application to select a different mount point.

What functionality am I loosing by omitting the mount manager? A little off topic: Is there a way to keep (or register) a mount point across user sessions / reboots?

Thanks,
Roland

[Liryna]

Ah thank you for your test @rkrikava !

Mount manager give you the ability to use Recycle bin and some advanced win32 api will only work on the device if the option is enabled.

The option is generally only used if you need such things.
I will see with @Maxhy about this behavior. I remember he told me something about it 😄 and that it is "normal".

But here the mount point reported should be updated according to the real one 👍

[Liryna]

@Maxhy confirmed me that when mount manager is used, we suggest the mount manager during IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME the letter to take BUT it is only a suggestion.

We should look in a way to update the real mount point or return an error.
-> It is probably going to be the first case.

[Liryna]

This will probably have to be done in 2.0.0 since it will need to change/create an IRP to update the user land FS with the real mount point before Mounted event.

For information, this is very rare to produce. You really need to make a race with another mount.

[Kerbox]

A bit off topic, but would you mind explaining a bit more why it is so important to keep kernel/user protocol compability in a minor release? Why couldn't it always be required that the same dokanX.dll/dokanX.sys pair is installed together? Is it because you want others to distribute their own dokanX.dll?

[Liryna]

Hi @Kerbox ,

Exactly, I would like that all application using dokan 1.x.x (with embedded dokan1.dll) can simply check if dokan1.sys is already present or not, if it is: they can safely know that it is compatible with their application.

This also gives the ability to have multiple software using different dokan version with the same MAJOR API on the system.

https://github.com/dokan-dev/dokany/wiki/How-to-package-your-application-with-Dokan

Tell me I answered correctly or if something is missing in the wiki 😃

[Kerbox]

That is a fair reason. Pity it makes fixing bugs like this and adding features a bit cumbersome, but as long as the major release schedule isn't too infrequent, I guess it's not a problem.

[trungdinhtrong]

I also encountered this issue. We have one particular Windows 10 machine where this bug is reproduced consistently. However, we can not reproduce it in other Windows machines that we have.

When we are waiting for the eventual notification, I'm wondering if there is any reliable way for our FS to find out which drive letter was actually assigned?

[Liryna]

I think the current workaround should probably be to scan all devices and find the one with the correct information that you have set in GetVolumeInformation (serial number, name, FS,...).

[trungdinhtrong]

Liryna: Thank you for the suggestion. That solution can work.

However, there is till a problem in this case. Supposed I request Dokany to mount at D: but it ends up mounting up E: instead:

• When I call DokanRemoveMountPoint, if I give it 'E' it will not unmount, and DokanMain() will not return.
• When I give it 'D' instead, DokanMain() will return, but drive E will not be reclaimed.

[Liryna]

@trungdinhtrong this behavior happens because we currently do not update the internal mountpoint with the final mountpoint that the kernel give us during IOCTL_MOUNTDEV_LINK_CREATED.

I will try to make a patch to fix this issue.

[Liryna]

Hi @trungdinhtrong ,

I made a change 60311c2 that will make able to use DokanRemoveMountPoint on the new mount point.
You can test it with snapshot build or wait 1.0.3. Tell me if this also worked on your side 👍

Currently userland has still no idea of the new mount point. This will only be done in 2.0.0.

[trungdinhtrong]

Hi @Liryna ,

Finally got a chance to verify your change - it works on my side also. Thank you :)

[winmaster121]

Here is How to Change Drive Letter name in Windows 10

Right click on the “Start” icon positioned at the lower left corner of your screen. Click on “Disk Management” to open Disk Management Settings Window.

Under the “Volume” section, right click on any hard drive and click on “Change Drive Letter and Paths”. For instance, right click on “New Volume (E:) and click on the same.

Click on “Change” to allow the name and path changes to be made on this drive.

Now, you can drop down the letters list to choose a new driver letter amongst the list of letters available. After selecting the desired choice, click on “OK”.

A warning window will be displayed on the screen saying that “some programs that rely on drive letters might not run correctly. Do you want to continue?” Click “Yes” to accept the driver letter and path changes.

Source:- [( http://merabheja.com/change-drive-letter-name-in-windows-10/ )]

[the-Arioch]

on occasion (linked above) YASFW would ignore provided mount point and would use first unused drive letter instead.

it that case during unmount both YASFW behavior changes (two "fairwell" lines are omitted from output) and - notifications of "new drive" and "removed drive" are not sent to userland applications.

i suspect

dokany/dokan/mount.c

Line 568 in 31f8381

BOOL DokanRemoveMountPointEx(LPCWSTR MountPoint, BOOL Safe) {

IsMountPointDriveLetter function there is redundantly called twice, and it is a bit dumb/ambiguous too.
The ambiguity point is more about #1017 though.

Frankly, the whole design seems off.

0. While it is most probable it is not given than every dokanlet would use Dokan1.dll, and if they would - they would often use their own local copy, maybe obsolete. I wonder if there maybe was reason to make Dokan userland API a COM/OLEAuto interface and server.
1. Userland won't have access to other desktops anyway, on terminal servers for example...
2. If it would - different users might have different sets of drive letters if overlapping.
3. The whole decision to broadcast or not may better be done comparing two lists of drive letters before and after operations, thus advertising ACTUAL changes and not what dokanlet thought chances would be (YASFW in example linked above does not guess right)

• https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlogicaldrives
• https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlogicaldrivestringsw

I wonder how Windows doing it on regular USB Thumb insertion, is there some monitoring part in every user session for it? Like that OLE DLL probably responsible for "Eject" command in Windows Explorer? or is there some system service that can be asked to initiate it on all the desktops?..

Dokany does not have a service but only a driver, so there is some kind of "who will wbe shouting out?" problem there indeed.

Funny thing is that IsMountPointDriveLetter does not actually check for drive being a letter, "7:\\" or even "\r:\\" would be perfectly OK for it, but DokanBroadcastLink would filter them out...

[the-Arioch]

every dokanlet would use .... often use their own local Dokan1.dll copy, maybe obsolete.

...or maybe even compiled and linked into .EXE from .OBJ files.

This has one more consequence - hard to make a shim/bridge/filter like layer.
I was musing about calls sequence mentioned in #1016 and the hypothetical prospect of implementing Windows-like file handles ARC and ignoring Dokany's stock cleanup calls..
And then about an APi logger.
A file logger.

But maybe it is stupid and no one actually can ever need that.
Even a crypto.
Basically some black box layer, implementing Dokan DLL APi both inside and outside, and (doing some voodoo) in between.
With some centralized, usable for non-programmer way to manage it, to inject it between Dokany core and a given dokanlet, without special hooks coded into either.

[Liryna]

it is not given than every dokanlet would use Dokan1.dll

You mean the one installed in system32 ? We actually suggest apps to use their own version

...or maybe even compiled and linked into .EXE from .OBJ files.

That's against the license 😉

It is true that a service could solve the broadcast issue. Actually, the Dokan legacy code had one but it was removed.
If the user-fs really need the global broadcast on other desktops, nothing blocks him to have its own service that does the broadcast.
@the-Arioch please do not hesitate to open a pull request with your suggested IsMountPointDriveLetter changes. I would be glad to review them!

[Liryna]

This is now fixed in 2.0.0 see changelog