Barbara Duprey ha scritto:
Marcello Romani wrote:
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.
I think you can get the effect of locking without creating a lock file
in the document's directory (though that sort of works and is quite
easy). If I were trying to do this, I'd look at how robust database
engines manage sharing among machines with different architectures and
with concurrent use, and approach a document as if the whole thing were
a database field (as a first cut), and maybe get into more sophisticated
things like tracking updates and committing them separately later. I
agree, it's definitely non-trivial and not realistically to be expected.
On the other hand -- maybe OOo could use such a database to manage its
(well, really our!) documents?
That's an interesting idea, but IMHO not feasible at all because each
OOo running instance has no idea whether there are other instances
running around (e.g. in a LAN context).
Remember: locking is all about communicationg between running software
instances. And in the case of OOo document locking, the only shared
resource you can consider available is the document itself.
One of the things that happens with the current approach is that
sometimes users are told that "somebody else is updating" because of a
left-over lock file. Not too bad if you know you're actually the only
one, you can get rid of the obsolete lock file. But what if there really
are other users? You have to check with them all, which may not be at
all feasible
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]
--
Marcello Romani
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
