Issue 96595 - cannot save-to a location with a dead, outdated, unconnected lockfile
Summary: cannot save-to a location with a dead, outdated, unconnected lockfile
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: usability
Depends on:
Reported: 2008-11-26 08:47 UTC by Frank Schönheit
Modified: 2017-05-20 10:55 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2008-11-26 08:47:43 UTC
- open an arbitrary text document, let's name it doc.odt
=> besides doc.odt, a hidden lock file ".~lock.doc.odt#" is created
- do something which lets OOo crash :), or simply kill it
- delete doc.odt from your disc
- start OOo
- create a new text document
- save it as doc.odt, to the very same location as the original doc.odt
=> the document is not saved, instead an error message pops up saying
  Error saving document ...:
  Object not accessible.
  The object cannot be accessed
  due to insufficient user rights.

There are at least two problems with this:

First, of course when I save a file which previously did not exist, the OOo
should simply ignore the existing lock file, since it's obviously out-of-date,
and not connected to the file which I'm just going to write.

Second, if this is not easily possible (though I strongly think OOo should *not*
behave this way), then the error message needs to be improved. At least, OOo
should tell the user that there is a problem with the file lock. It took me
*days* to find out why the heck OOo refused to save a document to "doc.odt" here ...
Comment 1 mikhail.voytenko 2008-11-26 09:18:32 UTC
When office crashes, it tries to remove the lock file. The probability of the
scenario when the crash handling is not able to remove the lock file is very
small, although of course it is possible in case the crash handling itself
crashes or can not be activated.

The killing of the process is a different story, we have no handler for this
case, so the lock file is not removed. The same problem with the lock file
happens when the network connection is suddenly broken and the document is
closed during the outage.

From my point of view even if there is no document with the specified name, we
can not just remove the lock file from another user in reliable manner. The
problem is that it is possible that another user creates the file exactly at the
same point of time. Timestamp based solution looks for me to unreliable in
network environment.

So currently I see only a UI improvement possibility for this case.
Comment 2 Marcus 2017-05-20 10:55:52 UTC
Reset assigne to the default "".