search

dokan-dev / dokany

User mode file system library for windows with FUSE Wrapper
http://dokan-dev.github.io
5.27k stars 665 forks source link

Problems using network share #963

Closed katcherw closed 3 years ago

katcherw commented 3 years ago

Environment

Check List

Description

Our Dokany-based virtual file system is working well so far using a local mount point. However, we then share the mounted folder as a network drive, and then we are seeing some problems. The most major problem is that in the Windows Explorer, we create a text file and then copy it to the same directory using ctrl-c/ctrl-v, but the copy of the text file appears as a directory. This is intermittent. In the callback code, we are not returning the original file as a directory and never setting the DokanyFileInfo->IsDirectory flag and never setting a directory attribute. Locally, this works fine, but remotely there is some directory attribute being set somewhere. Here is a ProcessMonitor dump and you can see that QueryNetworkOpenInformation shows a D flag in FileAttributes. Locally, only the A flag is set.

image

To debug this, we were attempting to compare with memfs. Unfortunately, we are running into another bug there. We can't always create a new directory. When using the File Explorer to create a new folder, it looks like it gets created okay (I see it in the explorer window), but when trying to access it, I get this message:

image

You can see in Process Monitor that it looks like the directory was created successfully, but then later it seems to not be able to recognize it anymore:

image

Remember, all this is working perfectly locally. This is also working perfectly, even remotely, with mirror. It's only memfs that has a problem, and our application is modeled off of memfs.

Have you ever seen these types of problems before? I can try to capture logs if it would be useful. I'm not sure how to debug this, because I don't see any problems in the log files, and not sure what would affect only a network share and not a local share. Any advice you can give would be much appreciated.

Logs

Please attach in separate files: mirror output, library logs and kernel logs. In case of BSOD, please attach minidump or dump analyze output.

Liryna commented 3 years ago

Hi @katcherw ,

Thanks for the report. The reason of the issue was the same as #909 I just made a fix https://github.com/dokan-dev/dokany/commit/7c1981577a521f956b3167348f2ee93421578934 that correct the behavior on my side. Let me know if you will still face the issue.

katcherw commented 3 years ago

Unfortunately this didn't solve the issue. I don't see any evidence of an extra slash anywhere, rather the problem is a file that was just created is somehow appearing with a directory attribute set even though the file system isn't setting one.

Liryna commented 3 years ago

If you rebuild memfs with the fix, are you now able to create a folder and acces it ? Can you now reproduce the same issue you are facing with memfs ?

katcherw commented 3 years ago

Even with the latest code that contains the fix, I still see the problem. All I need to do is start memfs like the following:

memfs /l c:\mnt

Then I share c:\mnt and give everybody read/write permission. On the remote computer I use File Explorer to go into the shared directory and then I create a new folder. The folder creates correctly. But when I double click to go into the folder, I get this error:

image

After hitting okay, I can go into the directory and create files in there without problems.

I am also uploading the logs. I added a few logs to dokany.lib to try to debug.

dokany.log

Bill

Liryna commented 3 years ago

@katcherw Thanks

In the log that you sent, there are sequential Opens that fails: \New folder\New folder \New folder \bill \bill\New folder

To finally create \New folder

I have never seen such behavior and do not understand why there is a double New folder, then a bill to finally create a New folder. Could you provide a procmon of this exact moment ?

Do you also face the issue when using the shared drive locally by using the unc ?

katcherw commented 3 years ago

It looks like the explorer client keeps looking for those old folders from old experiments, that's why you are seeing the additional opens. This time, I created a new mount point so the client doesn't ask for old data.

I am uploading a new log file, the procmon dump, and a wireshark capture:

dokany.log dokany1.pml.zip dokany1.pcapng.zip

I see in the procmon that it creates New Folder, queries it, but then suddenly can't open it anymore:

image

I don't see these creates in the Wireshark, so I'm confused where these calls are going. I tried mirror again, and it works perfectly fine.

I tried to use a local unc path, but I can't get it to work yet. I ran: memfs.exe /d /l c:\mnt /n /u \myfs\myfs1 but it keeps saying Windows can't access that location.

Bill

katcherw commented 3 years ago

I'm still not sure what's causing the problem in memfs. But we figured out the original problem in our own file system. I'll explain it here in case somebody else runs into the same thing.

To summarize, the symptom was that attributes of a file after creating a regular file was being reported as a directory. This was only happening on a remote client after sharing the mounted folder. Additionally, the problem went away when disabling the SMB client cache. Another symptom was that the security tab wouldn't appear, also only on remote clients.

The cause of the problem turned out to be that we weren't filling in the fileIndex correctly in GetFileInformation. Apparently, the SMB client cache relies on a unique id to look up the proper attribute. The local file system must be more forgiving if this value is not unique. Once we ensured there was a unique number, everything started working again.

Liryna commented 3 years ago

Thank you for your investigation and sharing the results!

For the file index, you want to say that the issue is in memfs too or not ? If yes, could you share how can it be fixed ?

katcherw commented 3 years ago

It looks like memfs handles this correctly from what I can tell. It uses an incrementing integer for every new file, so that should work.

Liryna commented 3 years ago

I agree. It looks to be correctly set.

Do you think this ticket can be closed or there is still something to investigate?

katcherw commented 3 years ago

The ticket can be closed. Thanks for your help.