Hi Volker,
the idea sounds very interesting. It should be checked whether it works
well in problematic heterogeneous networks, where the old file locking
had problems.
If this solution behaves itself consistently, I see no problem to
integrate it in framework.
Having a byte that is never accessed in a document is problematic, but
we could use the lock files further and lock an unused byte in the lock
file. Additionally the lock file allows better notification in case the
document is locked. And in case the lock file has the byte not locked,
it can be just removed then.
Thank you for the suggestion.
Best regards,
Mikhail.
On 10/23/08 14:44, Volker Lendecke wrote:
Hi, Mikhail!
Kay Koll from SUN has given me your contact and has asked me
to CC [EMAIL PROTECTED] I'm not sure if that
mailing list is the right forum for that kind of question,
so please tell me if it's an abuse.
At a customer site I recently discovered that OpenOffice 3
uses a lock file to coordinate access between different
users. This is much better than the incompatible locking
versions that OpenOffice 2 used on Windows (share modes) and
on Linux (fcntl locks). However, I have seen the problem
that the lock file stays around when a client crashes. This
seems to work fine if the same clients re-opens the file,
but does not work if another client wants to do that.
From my point of view this might be solvable by a byte range
lock. When a file is open, lock a byte and keep that lock
held by the process that has the file open. Because Windows
has mandatory byte range lock semantics, this should be a
byte that is never actually being accessed.
Using a byte range lock from what I see is interoperable.
Windows client -> Windows server does it, Linux client ->
cifsfs -> Windows server does it, Linux client -> NFS -> NFS
server does it also. The trick is that with "posix locking =
yes" (the default), Samba also propagates the brlocks
between cifs and nfs.
Would it be an option that OpenOffice could use this locking
scheme to figure out if a file having a lock file around
actually still is open?
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
