Adam Megacz wrote: > Russ Allbery <[EMAIL PROTECTED]> writes: >> I thought, on Linux at least, that some combination of the cache manager >> and the generic file system layer caused byte-range locking to work on the >> local host even though other hosts wouldn't see the lock. > > Crud, you're right. Argh. I wrote+tested the sqlite patch on MacOSX > (and it worked properly there, too). > > Any suggestions? Is Linux the only client platform that engages in > this degree of superfakery?
The OpenAFS for Windows 1.5.x client enforces byte range locking and mandatory locks locally but can't do so for remote users. Previously, all lock requests were granted even though no locks were obtained. > I'm really convinced at this point that the byte-range-lock-faking > (which I assume was introduced by Transarc) was/is an incredibly bad > idea and a dangerous thing. I mean really... unix/posix apps don't > ask for byte range locks unless they have a good reason for doing so. There is nothing wrong with a client grabbing a full file lock on behalf of an application when the application requests a lock on a subset of the range provided that the client is capable of managing all of the byte range allocations locally. A remote client in that case would in turn see that the file is locked (even if the locks are advisory.) What is dangerous is when a request for a byte-range lock succeeds when no lock on the file is actually obtained from the file server. Matt Benjamin had been working on patches for the UNIX AFS client that would provide equivalent functionality to that which is now found in the Windows client. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
