Luke Skywalker

Hello to all.
I found that the windows API LockFile has a strange behavior in some particular situations.
I'll try to describe the setup, the expected behavior and the real one.
I was using two "windows vista business" PCs, both 32bit.
One of them ("A") is sharing a folder to the other ("B").
They both are in a domain, I'm logged into both with the same domain user, which is also a local machine administrator. I gave the "coowner" permissions to myself on the network share.

From machine "A" I lock byte 100 of the file "test.txt" which is in that folder (a local folder to machine "A").
I then do the same from machine "B", trying to lock byte 100 of the same file, which I see in the network folder.

The expected behavior is that I should be able to get the lock from machine A and get an error from machine B, telling me that the lock could not be acquired.
I thoroughly read LockFile's documentation (and even tried LockFileEx) and everything assures me that I should get this kind of response.
Moreover, the failing LockFile function should return immediatly since I specified not to wait. This is what it has always done in the past.
As a matter of fact, this is exactly what I get if one of the two PCs does NOT have Vista in it.

When both of them are running Vista, however, I get stuck: the LockFile function running in machine "B" does not return, as if it were waiting for the lock to be freed in order to acquire it.
As long as I don't release that lock from machine "A", B's application is freezed, and so is the network share if I try to navigate using explorer.
As soon as the lock gets released from "A", "B" acquires it correctly.
Not quite enough, if I firstly get the lock from "B", calling the same from "A" does what is meant to be done: it quickly returns an error without blocking program execution for a long time.

This is not quite ok, to me.
Shortly:
1) locks are consistent, meaning that I cannot get a lock on a file region that is being locked by someone else: that's good
2) the LockFile API usually does its jobs, returning at once if a lock could be obtained or not
3) under some circumstances, the LockFile API waits the lock to be freed even if it should not wait. Besides that, under such circumstances it exibits an unconsistent behavior.

To clarify, I'll call "server" the machine sharing the folder, "client" the one seeing that folder as a network share.
The circumstances I talk about in point 3 are:
a) server locks a file at position X
b) a client tries to lock the same file at any position
or
a) a client locks a file at position X on the server's share
b) another client tries to lock the same file at any position

I want to underline that, in these two scenarios, the second one trying to get the lock is not able to acquire it if it is on a different file position (I'm currently trying to lock only 1 byte at the time).
This is a second issue, looks like the file is exclusively locked by the server.
Anyway, I can place locks on different file positions from different program instances if I do that on the server itself...

On the other hand, this situation behaves normally:
a) a client locks a file at position X on the server's share
b) the server tries to lock the same file at any position (except X)

Did anyone had something similar to this
Is this a Vista bug, maybe relating some low-level locking mechanism or the API redirector

If you want more informations, simply ask me.
Thank you in advance for your help
Luke


Re: General Windows Vista Development Issues LockFile through a network share

Luke Skywalker

I checked again my code and I've found I was partly wrong, so I'll clarify:
From a client...
  1. ...when trying to acquire a lock on a file position that already has a lock belonging to a different client (or to the server itself), LockFile is still not returning an answer, it either returns "ok, I did it" or waits until it can do it successfully.
  2. ...when trying to acquire a lock on a file position that doesn't have a lock at all, I'm able to complete the locking operation without problems (this is where I was doing wrong - sorry about that!)
I'm assuming here that both the "server" and the "clients" are running Microsoft Vista.
If one of them is not running Vista, the issue I'm talking about does not happen.

Does someone have an idea

I've found a workaround for this, asyncrously opening the file, trying the lock with LockFileEx and then polling if the lock could be get using GetOverlappedResult(), waiting and then repeating the check a number of times. If it is not available when my retry count is zeroed, I cancel the IO operation and return an error code.
This does work, but this is not the clean way...
The LockFile API has a documented behavior, and it does not behave that way.
That's the point, in my opinion...




Re: General Windows Vista Development Issues LockFile through a network share

Luke Skywalker

It seems that someone else found my issues: look at this post
I'm going to try the hack they suggest, but I'm looking forward some kind of fix, at this point...




Re: General Windows Vista Development Issues LockFile through a network share

Luke Skywalker

As JoeDMInc correctly says, it looks that the new SMB2 protocol developed for Windows Vista has some undocumented problem..

I've tried his suggested workaround and I can confirm that disabling the SMB2 protocol on the "server" machine solves the issues I'm experiencing:

To disable SMB2 (on the machine hosting the shared folder), create a DWORD value named "SMB2" and set it to "0", under the registry key HKEY_LOCAL_MACHINE\System\ControlSet\Services\LanManServer\Parameters
Then reboot

I don't know if disabling SMB2 has side effects, use at your own risk...
Anyway my guess is that, not having SMB2 enabled, the computers will negotiate the SMB1 protocol, that is not flawed...

This is a work-around, anyway. I think an official fix should be released for this.