Exactly - as this is the only place where it makes sense.
Not really - it causes problems when you try to edit a document that you
have read/write privs for, but the doc is located in a folder where you
do NOT have privs to create NEW files. I know, because this bug has
created big problems for me - but when I reported it, of course I was
told it isn't a bug, it is an 'improvement'... right, it is an
improvement that changes the way it worked for YEARS, and caused (and
still causes) me no end of grief.
I would *love* the ability to change the path for the lock files... or
better yet, I'd prefer for OOo to go back to the way it determined if a
file was being edited or not prior to the change (don't remember which
version this changed in, but it was some time ago)...
Thanks (again) devs..
Did you open a bug report with an appropriate description (ie, unable to
open a document read-only in a directory to which you cannot write...
Hard to argue with "not able to open a document for edit in a directory
you cannot write").
If they shoot you down, then change it to enhancement and convince
others to vote on it. Not reasonable to expect an enhancement to be
created just because it is something that you want. On the other hand,
if you want it as well as a 200 of your closest friends and relatives it
is more likely to receive attention.
Finally, perhaps you can implement this yourself, but, there are very
specific reasons that it is now done this way. For years, there were
complaints of how it used to be handled because of specific networking
shares (or something like that). Because of this, I doubt that they will
revert to the old method without making it a configuration specific
thing (or perhaps setting something in the environment).
I know about concurrent access problems.
And I agree that the current behavior must be the default.
But with the "not able to open a document for edit in a directory you
cannot write" problem, or in our case a shared filesystem that plays
tricks, a way to specify another place for the lock file could be great.
--
Sébastien Moretti
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
