Mount Manager about dokany HOT 15 CLOSED

About Volume Links on current branch state.
I successfully created drive letter with SetVolumeMountPoint (IOCTL_MOUNTMGR_CREATE_POINT is behind) which make it visible on mountvol DOS utility with the associated ??\Volume{x} link. But diskpart, fltmc or diskmgmt.msc can't still list it. Moreover FileSpy result to a timeout when attaching to the drive (probably related to fltmc error). Current Dokan code is wrong because it still allocate a custom ??\Volume{x} in addition to the one created by Mount Manager, this could be the reason.

Moreover Mount Manager keep links permanent after a reboot which can result to a current drive letter use error if the computer/dokanmounter was improperly shutdown. DokanLibrary should be able to recover from it and reuse the letter.

from dokany.

mountmanager branch is now stable enough to be tested :).
Anyone interested about it, feedbacks would be great if you can allocate some time for code review (don't take care about git history, just the general diff with master) and tests before the merge.
Special ping to @marinkobabic @accorp @kenjiuno @js69 😄

Thanks!

from dokany.

Beta release added: https://github.com/dokan-dev/dokany/releases/tag/v0.8.1-beta
It is a quick build so I did not changed the version of the binaries.

@Maxhy , I tested on my win10 and I have to kill explorer to see the device :(

from dokany.

@Liryna ok thanks. Network drive only or even regular virtual drive doesn't show up without explorer kill?

from dokany.

My fault ! I had to clean my register. Everything work (just have to f5 on explorer to see it)

from dokany.

For what it's worth - all (stable) Dokan.NET tests pass on this version of Dokany.
👍

from dokany.

@Maxhy
Issue: Same as what I faced before - Mirror is started but device is not mounted.

1-Play with dokan: mount / unmount a couple of times with mirror.exe (mirror.exe /r C:\Users /l m)
->Reboot
1-Mount with mirror.exe - mirror.exe /r C:\Users /l m
2>m:
2>dir
...work
1- ctrl +c the mirror.exe
2>dir
The system cannot find the path specified. (normal)
1- mirror.exe /r C:\Users /l m
2>dir <- In the same shell as the first dir
The system cannot find the path specified.

Logs of second mount after reboot: http://pastebin.com/ACMqb0uN

I have to clean register by removing all key starting by # in HKLM/SYSTEM/MountedDevices to be able to mount again.

Thank you @viciousviper, so no changes to make to the wrapper 👍

from dokany.

Ok @Liryna, I believe it is related to https://msdn.microsoft.com/en-us/library/windows/hardware/ff560461%28v=vs.85%29.aspx
If the input to this IOCTL is ("\DosDevices\X:", NULL, NULL) where X is the current drive letter for the volume indicated in the input triple, the mount manager adds a special entry to its database indicating that the client does not require a drive letter. On subsequent reboots, the mount manager will not assign a default drive letter to the volume.

from dokany.

@kenjiuno, following your #47 (comment) you will be interested to know that latest commit fb32a62 on mountmanager branch implements correctly UNC provider now.
After building latest change, you can use the mirror this way: mirror.exe /r c:\test /l m /n /u \localhost\myunc

Then you will be able to access it through M drive or \\localhost\myunc\.

@Liryna this commit should also fix your issue. Be aware that mountmanager is now an option. To use it you should start the mirror with /g parameter.

from dokany.

Hi Maxhy

• What happens when DokanOptions->MountPoint and DokanOptions->UNCName is null?
• Please add more logging information
• Now you have the possiblility to run DefineDosDevice optionally if somebody wants to have the drive only visible in his Windows session. This means a new option can be made available. In the actual version of dokan if you have two users logged in into the windows, both of them will see the mounted drives.
• DokanDbgPrintW, DokanDbgPrint, DbgPrint, DbgPrintW - when to use which of them. It's all mixed
• DokanSendVolumeArrivalNotification should use DokanSendVolumeCreatePoint or just remove the code from DokanSendVolumeArrivalNotification which is part of DokanSendVolumeCreatePoint

In generally it looks very good!

Thanks for the great job 😄

from dokany.

Thank you for your positive feedback marinkobabic.

• If DokanOptions->MountPoint and DokanOptions->UNCName is null then you have two cases:
  • you're using Mount Manager, Windows will automatically assign a drive and notify Dokan through IOCTL_MOUNTDEV_LINK_CREATED.
  • you're not using Mount Manager, you will have a working volume but no way to access it directly. That's said, it could be excepted for some use (ok not a lot of people want to do that).
• I will try to add more logs but feel free to suggest what is missing if you see something
• Yes, having an option to mount the drive globally or for current user session was on my mind too 😄. But I want to do that after mountmanager branch merge.
• Dokan debugging functions is a mess from the original code. Some cleanup should be done but this should be a separate discussion.
• Indeed, I'm gonna to remove the duplicate code on DokanSendVolumeArrivalNotification (test artifacts). Thank you!

from dokany.

Just an additional Comment:
Actually the creating of a device and mounting of the device is in once place. This seems to me somehow wrong.

• An application can create a device and then execute mount/unmount several times without the delete and recreate the device.
• One device can be mounted to different mount points at the same time

This are the reasons I would keep this two things in future versions separate in minimum on the driver level. Actually it's not related to the Mount Manager changes you have made so far.

from dokany.

This has always bothered me too, a new issue should be opened for this. Please feel free to create it, it will be handled when I will get some free time again or if someone is willing to do it through a PR. But I agree with your comment.

from dokany.

I'm glad to say after 6 months that this is now merged :).

from dokany.

🍺

from dokany.