why doesn't the kernel enforce oplocks? (was: Re: [Samba] Re: How Samba let us down)
ben at blarg.net
Thu Oct 24 21:00:25 GMT 2002
I guess what I am thinking about is how difficult it seems to be for
programs to actually cooperate with one another well enough to avoid
corrupting files. I know from experience that using flock() effectively
for making anything trustworthy that's more complicated than creating
lock files can be very difficult if not impossible.
A kernel supported api for locking files (maybe with timeouts and mutex
values) that actually enforced the file locks, instead of relying on
applications to be friendly to one another might (I think would) make
programming some user space apps a lot easier.
Samba could take advantage of such an api to make oplocks safe even when
the files in the filesystem are being accessed and modified by other
applications on the system. It could also leverage such an api to help
poorly written Windows applications from corrupting their own files.
On Thu, Oct 24, 2002 at 06:53:53PM +0000, jra at dp.samba.org wrote:
> Samba and vi don't have to co-operate, Samba just allows Windows apps to
> see each others byte-range locks. It's the apps on Windows and the UNIX
> apps that have to co-operate.
More information about the samba-technical