Open GoogleCodeExporter opened 8 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:
- 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:
- 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:
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
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
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
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
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
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
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
Original issue reported on code.google.com by
smurf...@gmail.com
on 14 Jan 2011 at 6:46