There are now at least two other identical questions for this problem:-
- Q55755
- Q55838
So, well done to Prolink for confirming that Restoring a default Profile is the way to fix this. Just one note:- the 5.x Profile has an identical location to the 4.x Profile folder.
2015-09-09 Update:
Prolink: “I’ve tried … (deleting, + ) restoring the default profile … Deleting .~lock files in the same file location … one thing I didn’t mention was that I use Dropbox to store files”
That after-thought mention of Dropbox is likely to be a key factor. Investigating it shows that yes, it has the precise method of working which is guaranteed to shaft LO/OO:
Dropbox:
Dropbox is a home for all your photos, docs, videos, and files. Anything you add to Dropbox will automatically show up on all your computers, phones and even the Dropbox website — so you can access your stuff from anywhere.
How does the Dropbox service work?
(here is the key phrase):- “…, and update linked devices when files are added, changed, or deleted.”
In brief, here is how LO/OO works, with emphasis upon how the use of Cloud storage such as Dropbox will inevitably cause problems:-
- LO maintains a user profile + a system profile.
- At program startup lockfiles are placed into both locations.
(the system profile lockfile is for the program startup
(the user profile lockfile is for each document opened)
-
LO/OO is NOT multi-user
(the lockfiles are there to ensure that no other user/process can open or change the document)
- At document close the doc lockfiles are removed
- At program shutdown the program lockfile is removed
- At next startup, if either lockfile is discovered, then the startup is stopped & an error message is issued.
Thus, the Dropfile service needs to be placed into suspension whilst LO/OO is active, or whatever Dropbox advises as the correct working method to prevent it from activating LO’s lock-checks. In particular, be careful to check that:-
- Dropbox is not copying either lockfile back into the Profile folders/directories after LO has removed it
- The Dropbox access does not lockout LO from being able to access it’s own files
(this was my constant experience with XP whilst using rsync - fantastically annoying)
If this helps then please tick the answer ()
…and/or show you like it with an uptick (∧)