search

pombreda / dokan

Automatically exported from code.google.com/p/dokan
0 stars 0 forks source link

0.6.0 Sharing on x64 Host Locks up network on Host #197

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Win x64 Pro running the .net 0.6.0 Mirror Example
2. Share a directory for everyone
3. Use win 7 x32 Pro to connect to the share

What is the expected output? 
- For the contents of the drive to be visible

What do you see instead?
- Explorer on the Win x32 machine locks up
- Then the network access by other machines to the Host also lock up..
- The only solution is to reboot the host.. THIS IS CRITICAL !!

What version of the product are you using? 
0.6.0

On what operating system?
- Win 7 x64 Pro for the Host
- Win 7 x32 Pro for the connecting client

Please provide any additional information below.
- The Other shares on that machine are visible
- No Debug information is printed from the driver
- Mirror appears to be active on the Host
- No windows Event messages are raised on the Host

Original issue reported on code.google.com by smurf...@gmail.com on 14 Jan 2011 at 6:46

GoogleCodeExporter commented 9 years ago 
The Mirror code is the .Net 4 Version 0.6.0
I have attached the sharing image, showing that the share is "Known" to the 
Host.
The Share is set to "Everyone: Read / Write"

Original comment by smurf...@gmail.com on 14 Jan 2011 at 7:05

Attachments:

GoogleCodeExporter commented 9 years ago 
- When the rebooted x64 Host is accesssed from XP, the Dokan share appears to 
be empty
- BUT, the Network does not become "locked up", and the XP browser can go and 
see the others shares on the Host without a problem
- Pressing F5 in the XP explorer, you can see the GetPath's being traveresed on 
the Host, and you can see it finding the subdirectories in the Share, but these 
are not visible
- This is also being tracked by http://liquesce.codeplex.com/workitem/8162

Original comment by smurf...@gmail.com on 14 Jan 2011 at 7:15

Attachments:

GoogleCodeExporter commented 9 years ago 
- The locking up only appears if you try to expand the share directory instance 
from the network share to view the subdirectories

Original comment by smurf...@gmail.com on 14 Jan 2011 at 7:24

Attachments:

GoogleCodeExporter commented 9 years ago 
Solved by this:

It seems that this is something to do with SMB 1 opportunistic locking.
The Liquesce service that is feeding the XP client will need to have the 
following registry key REG_DWORD value set to 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Ena
bleOplocks

See the following for an explanation of the setting: 
http://support.microsoft.com/kb/296264

Original comment by smurf...@gmail.com on 29 Apr 2012 at 5:53

GoogleCodeExporter commented 9 years ago 
I have the same issue. But the mentioned registry setting is not really the 
fix, as it can cause perf issues.

Instead of it I have changed the sys/fsctrl.c:

DokanUserFsRequest()....

case FSCTL_REQUEST_OPLOCK_LEVEL_1:
case FSCTL_REQUEST_OPLOCK_LEVEL_2:
case FSCTL_REQUEST_BATCH_OPLOCK:
case FSCTL_REQUEST_BATCH_OPLOCK:
case FSCTL_OPLOCK_BREAK_ACKNOWLEDGE:
case FSCTL_OPBATCH_ACK_CLOSE_PENDING:
case FSCTL_OPLOCK_BREAK_ACK_NO_2:
case FSCTL_OPLOCK_BREAK_NOTIFY:
     status = STATUS_NOT_IMPLEMENTED;
break;

So it does not lock up anymore. BUT I discovered another maybe related issue 
with this: When I try to copy a file larger than 4 MB from a W7/64 client to a 
W7/64 server I got "insuffincent resource" error. I tried to debug it, but the 
error comes from the client's network layer, it is not on the server. Wonder if 
anybody else got this?

Besides is there a documentation which describes how "not to implement" oplock 
protocol properly in a driver? I figured out that it is not mandatory to 
implement it, but I'm not sure I got it right with the code above!

Thanks!

Original comment by kaqk...@gmail.com on 9 Jul 2012 at 5:25

GoogleCodeExporter commented 9 years ago 
I have discovered that the insufficent resource issue could be different:

http://code.google.com/p/encfs/issues/detail?can=1&start=0&num=100&q=0x800705AA&
colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&groupby=&sor
t=&id=133

Original comment by kaqk...@gmail.com on 1 Aug 2012 at 2:13

GoogleCodeExporter commented 9 years ago 
Not sure is it the same case but my Win7 x64 tends to send new write before old 
has finished when dealing with large files after I implemented locking and 
DokanResetTimeout the Insuficient Resource issue was gone. Hope it helps.

Original comment by mladenov...@gmail.com on 9 Aug 2012 at 4:17

GoogleCodeExporter commented 9 years ago 
Hi, thanks for the info! I see that the write requests are q-ing up alright. 
Surprisingly, when the error pops up on the client, the file is already on the 
server! So it goes thtu, but the client still thinks something is not ok.

When you say you have implemented locking you meant byte level locking, or 
oplocks perhaps? Did you modify the kernel driver, or you modified only the 
user level code? I would really appreciate if you can share some more details 
:) Thanks!

Original comment by kaqk...@gmail.com on 10 Aug 2012 at 8:14

GoogleCodeExporter commented 9 years ago 
I implementd handle level locking(serialized write requests,made write thread 
safe on user level). I didn't notice same behavior on xp or even win7 x86 ,but 
it seams that x64 explorer handles pending operations from dokan driver 
differently.

Original comment by mladenov...@gmail.com on 10 Aug 2012 at 9:34

GoogleCodeExporter commented 9 years ago 
I have serialized the writes too. Still having the problem :( It just fails 
much slower. Honestly, without having the windows source code to look at, it is 
quite hopeless to fix. (Or without having a driver expert with 10+ yrs of 
experience...)

Original comment by kaqk...@gmail.com on 15 Aug 2012 at 12:51