Stop documents being blocked from editing

Frequently, documents that I have created show a box about being blocked from editing and offers me the chance to open a read-only or an editable copy.
It’s my document on my machine where I am the administrator and sole user, and I find it very annoying that I can’'t stop a program on my own computer from locking me out.
Is there a simple way to stop this, even if it can’t be reversed? If not, why not?
This just seems to happen randomly, and sometimes it will happen with a document one time and not the next. It happened today with a spreadsheet I created last night, so it’s not just Writer affected.
I have a screenshot:

(Edit: activated screenshot -AK)

And the message box exactly says … what?

I experience such inconvenience when I “cross-open” a file residing in another userid’s directory and the group permissions are insufficient. If you’re in multi-user configuration on your computer, check access rights. As said in the answer below, this is not an LO issue. LO tries its best to open the file instead of refusing to do so. You can always push the Edit document button, save a copy in your local directory and later deal with the permission problem.

I find this happens on my Windows 7 PC, but (as far as I have noticed) only with old documents saved in .doc format. Since switching to LO I save Writer’s working documents only in .odt and PDF (despite cries of distress from some MS Word users) and the problem seems not to recur.

For old files, when it does happen, the behaviour is not entirely consistent, but the dialog telling me the document is read-only offers the option of opening in that form. This produces a read-only text with an Edit Document button at the top right of the document window. Clicking on that again produces results that are not 100% consistent, but with a little lateral thinkingdo let me have an editable document which I then save in odt format. I have never yet experienced a file that has defeated my wish to edit it.

I have not tried to explore what is going on in any depth, but merely imagine this might have something to do with the way Windows archives old files, meaning it is not an LO problem. Unless, of course, one of our experts can tell us I am wrong.

The message I draw from all this is to confirm my belief that –

  1. A working file should never be saved in an MS proprietary format (doc, docx, docx extended, etc). Save working files to be used in LO only in an odf format (odt etc).

  2. Life is much easier if we convert an editable word processor file to an MS format only when sending it to a recipient who absolutely insists. And then only after pointing out that MS now says all its recent products can handle odf files.

The screenshot shows clearly that the problem is (stalled?) lockfile: it is the only source of information where LO can take that data (who and when opened the file).

It is unclear what is the version of LO used; e.g., in recent LO, when it detects that it’s current user on current system, it would simply ignore the lockfile, and otherwise, would offer to open for editing. However, it’s enough to find and remove the hidden lockfile placed right in the same directory with the document, and named like .~lock.filename.ext#.

Mike, in answer to you, I am using Version: (x64).and this is not a multiuser setup. The lockfile appears on the desktop and when I delete it, it comes right back the next or second time I reopen.
I would not only like to know how to stop it, but to stop it for good.

To know that, first thing is to understand:

  1. Why the file is left? Lockfiles are always created (no matter if that’s a multiuser setup or not) when you open the file; and they should be removed automatically when you close your file normally. If it’s left, then something abnormal must happen (program crashed?) - so often? each time or each other time? so that the next time you open the file, you already have that residual file present. A file causes constant crashers?

  2. Why the file is not ignored? As I mentioned, when that’s a file left from the same user and system, it should normally be silently ignored. It wouldn’t be ignored if username is for some reason different (I can’t think why would that happen on single-user setup); or if the lockfile is not the only thing left - e.g., the file is also locked on filesystem level (or, say, an antivirus blocks the operations)…

By the way: did you try temporarily disable antivirus to test if that’s it or not?