I've also run into the same situation - it works locally but not on samba shares. At first I though maybe wine server was just keeping its own table of locks, but I glanced through the code and it looks like its getting/setting the lock with the inode somehow (I'm pretty new to linux so I wouldn't know how that part works). It must be doing something about the advisory/mandatory problem because my read tests did fail on locked regions when performed on the same machine...
Regarding it not working on samba shares - I believe that samba just ignores unix locks because of the advisory/mandatory locking issue - which means that samba must be creating its own internal lock table. If this is the case, then it shouldn't be to difficult for wineserver to detect if the device is samba and map the lock requests through to samba when necessary (samba does have an api doesn't it?). I'll look into this when I get a chance - but maybe someone who is more familiar with the issue could crank it out pretty quickly?
- Eric Noel
----- Original Message ----- From: "Paul McNett" p@ulmcnett.com To: wine-devel@winehq.com Sent: Friday, March 21, 2003 4:34 PM Subject: Re: LockFile() and UnlockFile() are working
Hi John K. Hohm,
On Friday 21 March 2003 12:15 pm, John K. Hohm wrote:
This resolution will make a ton of business apps based
on desktop
database software that much closer to working.
I'm not so sure. I expect most database software
depends on the
mandatory nature of LockFile(), i.e. that a ReadFile()
or WriteFile()
from another process on a locked region fails with
ERROR_LOCK_VIOLATION.
Yep, you seem to be correct.
Typically, one process will LockFile() an area, then
update on-disk
structures in such a way that another process reading
during the update
would get confused were it not for ReadFile() refusing
to read the locked
bytes. Note that the reading process does not
LockFile() to read, it
just tries ReadFile() and handles its failure (typically
by waiting and
trying again later).
For database software that uses read/write locks via
LockFileEx(), the
standard Unix advisory lock semantics are just fine, and
those patches
are indeed the ticket. However, advisory locking is
generally more
difficult to manage, and LockFileEx() is not supported
on Windows
95/98/Me, so I doubt many apps use it.
I just confirmed... while locking seems to work if two
instances of Visual
Foxpro are running on Wine on the same machine, it DOES
NOT work over the
network. I had one instance on Wine and one instance on
WinNT. Both
instances were interacting with the same table on a third
machine. The two
instances of Visual FoxPro did not respect each other's
locks. Bummer.
Big bummer.
From what I can tell, mandatory locking on Linux
involves tricks like
using a special mount option, and setting the SGID bit
of the file to be
locked before the locking process starts; I'm not sure
which other Unixen
even support it.
So... chances of this ever getting implemented on Wine
are, in your opinion,
pretty slim? If so that's too bad, because I saw a great
possibility of
porting lots of legacy business apps over to Linux using
Wine. There are,
as I said before, a ton of apps out there built on desktop
database
software... bummer.
-- Paul McNett - p@ulmcnett.com Hollister, California, USA