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.
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.
Marcello
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
