Barbara Duprey ha scritto:
Marcello Romani wrote:
Programmer In Training ha scritto:
On 1/9/2010 10:34 AM, Marcello Romani wrote:
Tanstaafl ha scritto:
On 2010-01-08, O. Felka ([email protected]) wrote:
OOo doesn't create a 'temp' file. This file beneath the document is
for the file-locking feature. It's not very helpful to create it
somewhere in the local environment of the user.
Ok, so how did OOo accomplish this before? The fact is, what I am
trying
to do used to work, and now it doesn't, so something changed and broke
the previous behavior.
I should be able to edit a document that I have read/write privileges
for, even if I don't have 'create' privs in that directory.
I think the problem here is how to find a reliable way for multiple
copies of OOo, possibly run by different users on different
machines, to
tell each other that a file is in use by one running copy of OOo, and
should be treated "read-only" by others instances of the program
accessing it.
Of course this problem already has a solution in all network
filesystems, but every OS and every network fs has its own sets of apis
and has differences in its behaviour with respect to locking.
So I think it's been judged simpler and safer to implement a
platform-agnostic application-specific solution. Think of it as a sort
of OOo-only file lock protocol.
OOo Gurus pleas correct me if I'm wrong.
HTH
Marcello
I dislike all forms of file locking. I find it useless and arbitrary.
I'm glad web servers don't engage in file locking, otherwise we'd never
be able to update our websites.
That statement is just plain stupid. File locking is essential in
network filesystems, otherwise you would risk to lose data if two
users where to edit the same file at the same time, without the OS or
the application telling one of them that the file is in write-mode by
the other.
No, locking can be done at other levels. For example, doing real-time
programming back in the early days of the System/360, we protected
critical code areas that were to be used by only one instance at a time
using the Test-and-Set (TS) operation. The first instance would pass the
test, do its thing, then clear the flag. During this time, any other
instance would fail the test and keep its hands off until the flag was
cleared and its TS passed. That protected the integrity of data storage
that might otherwise get mangled. And I think even today, many databases
are protected at the field level using various mechanisms to control the
commits.
While I find the matter fascinating, I don't think those "levels" are
the same OOo developers are faced with.
The scenario here is: one user opens an OOo document on a fileserver, in
write mode (i.e., she can edit the file and save it back).
Meanwhile, another user opens the same file. This last user _must_ be
notified that someone else is modifying the file, otherwise Bad Things
will surely happen.
So we have three phisically different machines: two clients and a file
server.
The only two ways (that I can think of) OOo can lock a file in this
situation are:
1) notifying the underlying OS;
2) implementing a sort of OOo-specific "lock protocol".
It might be tricky to implement 1) in a portable way across all
combinations of operating systems and network file systems.
Method 2) has its shortcomings too (as this thread demonstrates), but
has been probably judged a better compromise by the developers.
But this has nothing to do with OOo, does it ?
Yes, because probably some similar way could be found that avoids the
clashes between OOo instances doing updates without needing to create a
lock file.
File locking has a lot to do with OOo. But I was referring to a
paragraph from PIT, that is clearly not related to OOo (please read it
again and it'll be clear).
Marcello
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
