LockFile() and UnlockFile() are working

[Eric]

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 at ulmcnett.com>
To: <wine-devel at 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 at ulmcnett.com
> Hollister, California, USA
>
>
>