Issue 96595

Summary: cannot save-to a location with a dead, outdated, unconnected lockfile
Product: General Reporter: Frank Schönheit <frank.schoenheit>
Component: uiAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, Mathias_Bauer, strob08
Version: OOo 3.0Keywords: usability
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

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 "issues@openoffice.apache.org".