Marcello Romani wrote:
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).
The database engines that operate across system platforms and over
networks have, I think, faced the same issues. People all over the
place, using their own machines, are updating the same networked
database. So if that networked "database" were an OOo document, the same
techniques might apply. Not saying it's likely, but we can dream, can't
we? (Unfortunately, development for Base has not had the resources to
look at this, although it is recognized as an issue.)
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.
It would be nice if "the document itself" were what is involved -- but
it's the lock file. The thing that was in the back of my mind for the
Test-and-Set example was that maybe an in-use flag could be set actually
within the stored file, tested before any update is committed, and
cleared when it's done. There'd still have to be a way to clear such a
flag with administrative action, probably, for situations where there is
no error-response logic able to run. And the setting and testing have to
be inseparable actions, to keep there from being intervals where two
instances can pass the test. Still think there may be some possibilities
here, though. As the OP mentioned, some fairly recent change seems to
have been involved that denies access now in a way it did not before,
and maybe could be rolled back. (Always assuming the change was in OOo,
of course, and not in his system's administration.) Anyway, this
conversation should probably move to the discuss list if we have more to
say.
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]
