Persistent locked files & Win95 (PR#15490)

[Jeremy Allison]

bscott at hamptonsys.com wrote:
> 
>   I do not know about the original poster, but here at Hampton Systems Group,
> I have noticed a... not quite a bug... maybe a "conflict of interest", with
> regards to oplocks.  I often edit Perl CGI scripts from my Win32 workstation.
> The scripts themselves reside on our Linux server.  Since an oplock is opened
> on those scripts by the Win32 client, the file is locked on the UNIX side,
> preventing the script from running ("Text file busy").
> 
>   I work around this problem by using "veto oplock files", but I regard that
> as inelegant.  I suspect, however, that the only way to implement a "proper"
> solution would be to add special support for the concept of oplocks to the
> Linux kernel.  File locking under UNIX is surprisingly primitive, given its
> general superiority.

Well, that's not really true. It's not possible to
emulate POSIX file locking under Win32 for example
(no range overlap, no range splitting or merging,
no lock upgrade/downgrade for example). The only
problem with POSIX file locking is some of the
braindead semantics with respect to close.

You are correct about the "proper" solution is
to add the oplock concept to the Linux kernel.

SGI are planning to do this, they already have
the oplock concept in IRIX to support Samba in
exactly this way and are intending to port
this code to Linux. I'm not sure of the timeframe,
I need to bug the guy who did the IRIX work in
order to get this done :-).

Regards,

	Jeremy Allison,
	Samba Team.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------