Problem description: File cannot be saved if Load LibreOffice at startup is checked (LibreOffice quickstart is on). There is a 50-60k system process that doen't quit even if you close the file by cancelling the changes.
If it saves the file then at the next reopening you cannot modify because the same system process is still on and the file is actually opened...
I could not reproduce it on local files!
Steps to reproduce:
1. Open network ods
2. Make a change
4. Error occurs
6. Quit LO
1. Open network ods
2. Make a change
4. Error doesn't occur and file is saved
5. Try to reopen
6. "File is opened by another user"
The issue is not influenced by antivirus. I tried with webroot on/off, Bitdefender on/off, without... Still the same.
Also the problem does not appear every time!!!! This is most frustrating...
For further tests/info please instruct me on what to do!
Operating System: Windows 7
Version: 126.96.36.199 release
Could you please take a look at bug 67885? I think it's the same as your second scenario (if so it doesn't related to quickstart).
As of your first scenario, you can open the document, but not save afterwards, right?
Hi, if I am meant:
Scenario 2 is what i got.
I can't reproduce Scenario 1 or don't know how to.
I have looked over bug 67885 and it behaves similar but not entirely. Also for that bug, when it happened, I had to close the Windows Eplorer window from which I started the file (or at least perform a back and forward on the folder to get a fresh refresh)
Fo the issue described above I found a workaround, which I do not like, but it works. If I do not use Load LibreOffice at startup at all, then the problem does not happen anymore on any of the computers/systems tested! In my opinion this must have something to do with quickstart.
In 4.0.5 and 4.1.1 release there is the same behaviour on 64bit and 32bit, Win 77 Home and Professional machines:
If I open a file from a network drive, make modifications and click save then the file is not saved with mess: Error saving the document XXXX.ods:
Access to P:\_Documente personale\Membrii familiei\copiii 2.ods was denied that there are no sufficient rights.
The same behaviour is with quick start on and off.
For me this is a showstopper, as I cannot use anymore neither 4.0.5 nor 4.1.1. Reverting back to 4.0.4 where this did not happen.
Tested with 188.8.131.52 on Win 7 64bit. The problem still remains for some ods files.
However, when I copied the data from the "broken" file to a new file (only numbers and formulas) and I redid the formatting by hand, the file could be saved on the network, so there is hope that something is better, but not yet reliable.
On the local drives I could work without any problems.
For the network scenario I tried with antivirus on/off but could not save.
Apache 4.0.1 worked without problems! on the same files... Too bad it has not yet the functionality of LibreOffice.
(In reply to comment #4)
> The same behaviour is with quick start on and off.
OK, so I'll correct the summary.
If you uninstall 'Libreoffice Windows Explorer extension', does the problem persist?
(In reply to comment #7)
> If you uninstall 'Libreoffice Windows Explorer extension', does the problem
@Robert Popa: Following Urmas suggestion: Please run LibreOffice installation, choose 'Modify' and uncheck the installation of Windows Explorer extensions. Does it solve your problem?
(In reply to comment #8)
> (In reply to comment #7)
> > If you uninstall 'Libreoffice Windows Explorer extension', does the problem
> > persist?
> @Robert Popa: Following Urmas suggestion: Please run LibreOffice
> installation, choose 'Modify' and uncheck the installation of Windows
> Explorer extensions. Does it solve your problem?
YES!!! It finally works! I could not get the files blocked anymore. I opened multiple Explorer Windows and every time the files opened correct.
Regarding save: I did multiple saves, very quick, and still the file did not block me to save it.
I guess this was the problem. However, why did we need the Windows Eplorer Extension in the first place? I don't know what it is used for... :(
(In reply to comment #9)
> YES!!! It finally works!
Great, thanks for confirming!
*** This bug has been marked as a duplicate of bug 67534 ***