Created attachment 83294 [details] Message if open with doubleclick in networkdrive Problem description: Steps to reproduce: 1. double click on a file in explorer, file are used from a unknow user 2. If it is open this file in dialog of Libreoffce... it can open 3. In OpenOffice 4.0.0 work it correct Current behavior: 4.0.4 Expected behavior: It should also open without error message Operating System: Windows 7 Version: 4.1.0.4 release Last worked in: 4.0.4.2 release
Is it a read-only share?
It is on a network drive, which has ALL right, works with OpenOffice 4.0.0 to read and write the crossroad of these files without the right change in the net. If I do not the file by double clicking in Explorer but about LibreOffice - open file-open, it works.
Hi, Could you please take a look at bug 67885 & bug 68082, Is it the same issue you have?
It could be the same problem under Umstaänden. But I'm not sure. OpenOffice 4.0.0 it works without problems, however.
(In reply to comment #4) > It could be the same problem under Umstaänden. But I'm not sure. I mean - Does it happens only when you're trying to open the document a second time (like the mentioned bugs), or you can't open the shared document at all, never?
Seems to have the same problem with versions LO from 4.0.5, also 4.1.0. I have to go back to 4.0.4.2 to be able to work properly. Windows 7 Synologic NAS
Note comment 6: the bug seems to have slipped in 4.0.5 Raised severity and added to MAB list.
@Mike: What kind of machine is providing the network drive in question? Another Windows machine? A Linux one? Or something else? What does "Umstaänden" mean? You are absolutely sure that double-clicking in Explorer, LibreOffice does not manage to open the file, but using LibreOffice's File>Open menu entry, it does? Are you absolutely sure it is the same LibreOffice installation in both cases that gets used?
Also the type of document might affect the behaviour, so what is it? .odt, .doc, .xlsx, etc?
(In reply to comment #8) > What does "Umstaänden" mean? "It could be the same problem under Umstaänden." -> "It could possibly be the same problem." (Mike, if you feel more comfortable writing in German, it might help if you write your German text alongside the---automatic?---translation into English.)
No, i had find this problem only with odf - files
It could be the same problem under circumstances that are similar to the problems. I can see the problems with ODF files.
hmm. a bug in the same area maybe, that seem to have been resolved around 4.0.4 Bug 60961
@Cor, we don't need pointers to other bugs that are "maybe" in "the same area". All that does is confuse things and cause scope bleed for a bug report. We need exactly reproducible narrowly defined bug reports. From a (virtual) machine running Windows 7, using the TDF LO 4.1.1.1, I could reproduce the problem: double-clicking an ODF document located on on a network share (exported by Samba on Linux, though, not Windows) in Explorer, LO claims it is locked by an "unknown user" (which certainly is not true). But just a few times, tens of times I could not, doing the exact same thing. Is this the case for the original bug reporter, too, that if he just tries again, it usually works? Or does it keep failing all the time for some document?
(In reply to comment #14) > @Cor, we don't need pointers to other bugs that are "maybe" in "the same > area". All that does is confuse things and cause scope bleed for a bug > report. We need exactly reproducible narrowly defined bug reports. I know - sometimes can resist. Sorry ..
On all Inatallations of LibreOffice 4.1.0.4 have it that PROBLEM! On 14 PC in a Network. IT is if I will OPEN ODF-Files in a network drive. IT is EXACT and real! Not mybe or the same. IT is exact this problem.
@Mike: I am not doubting you have a problem. I just needed replies to my questions. But you chose not to give them. Oh well.
This problem works on a netdrive Novell Open Enterprise Server with Netware in the /system! Netware Version 6.5.7. Acutal Novell Client Windows 7/8 for Novell Netware
OK, that is quite relevant information that you should have told right at the start. Sigh. Anyway, I have no way to reproduce it then.
(In reply to comment #16) > On all Inatallations of LibreOffice 4.1.0.4 have it that PROBLEM! On 14 PC > in a Network. IT is if I will OPEN ODF-Files in a network drive. IT is EXACT > and real! > Not mybe or the same. > IT is exact this problem. Downgrading to 4.0.5 fixed the problem for me, for now. I've found the same issue as noted: https://bugs.freedesktop.org/show_bug.cgi?id=67885
OpenOffice 4.0.0. work it correct to say in 4.0.X version of LibreOffice. Tich I think the problem is due to a change in the interface as in previous versions ond in Open Office is calling a double possible without these problems. I will be the bard still check on a Microsoft network drive!
@jared: when you added comment 20, the status and severity of this bug were changed to NEEDINFO and Normal. Was that by intention?
No, it is a important error.... sorry!
(In reply to comment #22) > @jared: when you added comment 20, the status and severity of this bug were > changed to NEEDINFO and Normal. > Was that by intention? sorry, I missed that I adjusted the status! thanks for catching it.
(In reply to comment #24) > sorry, I missed that I adjusted the status! thanks for catching it. No problem. Now and then, it looks as if IssueZilla adjusts something itself. It happened with me too once.
(In reply to comment #19) > OK, that is quite relevant information that you should have told right at > the start. Sigh. Anyway, I have no way to reproduce it then. Hi Tor, I have the same problem on my home network between a Windows 7 client (fully patched) and a simple NAS device (Conceptronic CH3MNAS) based on Linux firmware. Using LO 4.0.2.2 works fine, upgrading to 4.0.5 and 4.1.0.4 invokes the problem of the topic starter. If you like I can try this at work on a Novel Open Enterprise Server version 2 with a Windows 7 client. Regards, David Schiebaan
Extra info Opening from windows explorer gives the problem (Linux bases synology network drive) Opening from LO with [File], [open] gives no problem whatsoever. So I think it is not a problem with the operating system (files locked or so) but within LO.
Hi, I've not seen this bug during a first search (stupid boy !), so I've opened bug 68757 ... for the same thing. I had not tried opening document within LibreOffice, and yes : - from explorer : locked by unknown user ( and not lock file is created) - within LibOffice : it's ok
*** Bug 68757 has been marked as a duplicate of this bug. ***
Yes, thats correct!
(In reply to comment #27) Extra info too Opening from windows explorer with double left click gives the problem (Novell OES network drive) Opening from windows explorer with right-click -> Open or right-click -> Open With gives "no problem" Opening from LO with [File], [open] gives "no problem". For me version 4.0.4 was ok. Problem appears with released versions 4.0.5 and 4.1.1. Seems there isn't the problem with nightly build Win-x86@6-debug 4.1.2 from 2013-09-01. I say 'seems' because, as it's a dev version, I've associated it manually with odf documents so I can open .odf with 4.1.2 with a double left click
Opening from windows explorer with double left click gives the problem (Novell OES network drive) - YES Opening from windows explorer with right-click -> Open or right-click -> Open With gives "no problem" - YES Opening from LO with [File], [open] gives "no problem". YES
This started for me when I upgraded to 4.0.5, so I then upgraded to 4.1.1.2 and the same behaviours persisted: - locking error by unknown user when double clicking on odt files using windows explorer on my Netgear NAS (\\NASName\dir\) - No lockfile (not visible in Windows explorer, not visible in linux) to delete. Lockfiles show up properly when editing a document though. - file opens properly if I use the writer file -> open dialogue - - odt files open fine when double clicking in windows explorer on my local PC - deleted %appdata%\libreoffice\4\user but no effect (https://wiki.documentfoundation.org/UserProfile) Have not turned off file locking (http://www.libreoffice.org/get-help/readme) because it worked before upgrade Have not turned off UseDocumentSystemFileLocking / UseDocumentOOoLockFile in main.xcf (http://ask.libreoffice.org/en/question/4055/how-can-i-unlockwriter-documents-to-edit-on-another-computer/) because it worked before upgrade Have not downgraded to 4.0.4 because I haven't found the link to it yet
- file also opens properly when using windows explorer, right click -> open with -> libreoffice writer
Sometimes in Windows 8 I do a second double click and it work. In Windows 7 it is click right and open with wirte better.
@Mike Silbermann: 'Version' field is for earliest version on which a bug is reproducible, so please don't change it to a newer version. See https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Version#How_we_use_this_field.
Ok--- thats ok!
Created attachment 85948 [details] error if double click Here a actuel error sign of double-click
(In reply to comment #36) > @Mike Silbermann: 'Version' field is for earliest version on which a bug is > reproducible, so please don't change it to a newer version I don't change anything in bug status but for me : 4.0.4 : ok 4.0.5 : bug 4.1.0 : not tested, sorry 4.1.1 : bug So the earliest version with bug is, numerically speaking, 4.0.5
4.0.4 it is ok...
Could it be that double click in Windows Explorer, apart from launching soffice.exe on the file, also (in parallel?) runs some "shell extension" or whatnot on the file (to produce a preview thumbnail, say), and those two, for whatever reason, interfere now since LO 4.0.5 while they did not yet in 4.0.4? The only mildly relevant-looking commit I found that is in libreoffice-4-0-5 but not in libreoffice-4-0-4 is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=f7ff371fdc4c44820a1cfae90c2f1af704f276a2> "bnc#829017 fix issue with negative seeks in win32 shell extension," though.
(In reply to comment #41) > The only mildly relevant-looking commit I found that is in libreoffice-4-0-5 > but not in libreoffice-4-0-4 is > <http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=f7ff371fdc4c44820a1cfae90c2f1af704f276a2> "bnc#829017 fix issue with > negative seeks in win32 shell extension," though. Stephan, the commit fixes basically the fact that on 64-bit systems the indexing was not working, because unsigned 32-bit integers were casting into signed 64-bit ones which was producing seeks off the end of the files. It is quite possible that since now the zip back-end works, it can take some time to read the content.xml and extract the text to index then. There might be a slight difference between the thumbnail extraction and the content.xml reading. Since this is a network drive, it is possible that using unbuffered read might mean a slowdown and the file being reported as being opened. TL;DR summary: there might be a problem if the zip streams are extracted one byte at a time, but that above-mentioned commit is correct and reverting it would mean that we cannot search odf document anymore.
*** Bug 69035 has been marked as a duplicate of this bug. ***
We've installed v4.0.5 on several PCs running Windows 7 and XP. The same problem occured with Windows 7 on network drives with open document files only when opening the documents from the windows explorer. Opening files directly in LibreOffice or with another file explorer works fine. It also seems to work fine in windows explorer if you wait for the progress bar in the path input zone to complete and disappear (takes 5-10 seconds on our machines). PCs running win XP don't have the problem.
Due to several comments, changed version for the earliest where users experienced the bug: 4.0.5 Best regards. JBF
*** Bug 69770 has been marked as a duplicate of this bug. ***
This bug is in MAB4.1 but it affects LO 4.0.5 too. Should it be moved to MAB4.0 ? Best regards. JBF
On a Windows7 computer, i copy some files from a Linux-samba share (O:) to a NAS (R:) R:\temp>copy o:test1.* . o:test1.cmd Overwrite .\test1.cmd? (Yes/No/All): a o:test1.ods o:test1.odt o:test1.odf 4 file(s) copied. R:\temp> On this NAS, i do a 'smbstatus' (after the 'copy' is finished!): Locked files: Pid Uid DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 2955 1000 DENY_WRITE 0x20089 RDONLY EXCLUSIVE+BATCH /mnt/array1/Documents temp/test1.odt Fri Sep 27 19:57:17 2013 2955 1000 DENY_ALL 0x30197 RDWR EXCLUSIVE+BATCH /mnt/array1/Documents temp/test1.cmd Fri Sep 27 19:57:16 2013 2955 1000 DENY_NONE 0x100001 RDONLY NONE /mnt/array1/Documents temp Fri Sep 27 19:48:51 2013 2955 1000 DENY_NONE 0x100020 RDONLY NONE /mnt/array1/Documents temp Fri Sep 27 19:02:57 2013 2955 1000 DENY_ALL 0x30197 RDWR EXCLUSIVE+BATCH /mnt/array1/Documents temp/test1.odf Fri Sep 27 19:57:16 2013 2955 1000 DENY_NONE 0x100001 RDONLY NONE /mnt/array1/Documents . Fri Sep 27 19:48:51 2013 2955 1000 DENY_ALL 0x30197 RDWR EXCLUSIVE+BATCH /mnt/array1/Documents temp/test1.ods Fri Sep 27 19:57:16 2013 root@LS-WXL0B9:/mnt/array1/Documents/temp# smbstatus --version Version 3.0.30-1.4.osstech root@LS-WXL0B9:/mnt/array1/Documents/temp# These locks are the cause of this 'bug'. I do not think it's a bug in LO (i think 'smb' is the cause)
Starting 'inotify -mc test1.odt', and than doing a copy gives: R:\temp>copy O:test1.odt . Overwrite .\test1.odt? (Yes/No/All): a 1 file(s) copied. R:\temp> output from inotifywait -mc test1.ord (on the NAS), notice the delay at the end.... ;) root@LS-WXL0B9:/mnt/array1/Documents/temp# inotifywait -mc test1.* | awk '{ print strftime(), $0; }' Setting up watches. Watches established. Fri Sep 27 20:23:21 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:21 CEST 2013 test1.odt,"CLOSE_NOWRITE,CLOSE", Fri Sep 27 20:23:21 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:21 CEST 2013 test1.odt,"CLOSE_NOWRITE,CLOSE", Fri Sep 27 20:23:23 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:23 CEST 2013 test1.odt,"CLOSE_WRITE,CLOSE", Fri Sep 27 20:23:23 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:23 CEST 2013 test1.odt,MODIFY, Fri Sep 27 20:23:23 CEST 2013 test1.odt,MODIFY, Fri Sep 27 20:23:23 CEST 2013 test1.odt,MODIFY, Fri Sep 27 20:23:23 CEST 2013 test1.odt,ATTRIB, Fri Sep 27 20:23:23 CEST 2013 test1.odt,"CLOSE_WRITE,CLOSE", Fri Sep 27 20:23:23 CEST 2013 test1.odt,ATTRIB, Fri Sep 27 20:23:24 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:26 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:28 CEST 2013 test1.odt,OPEN, Fri Sep 27 20:23:45 CEST 2013 test1.odt,"CLOSE_NOWRITE,CLOSE", Fri Sep 27 20:23:48 CEST 2013 test1.odt,"CLOSE_NOWRITE,CLOSE", Fri Sep 27 20:23:48 CEST 2013 test1.odt,"CLOSE_NOWRITE,CLOSE",
Why work it with LO 4.1.x with a doc file or docx, but not with odt...? If I take a early LO ( 4.0. or 3.6.x...) it works correct? It is a change in LO... older parts was clean for faster runnig? I dont know, but the problem is only in net-drive of novell netware or i had hear in linux drives. If I open this out of the programm it work correct...
Does it related somehow to Bug 68487? @Anyone who have this problem: Could you please run LO installation, uninstall Shell extensions, and report if it solves the problem.
(In reply to comment #51) > Does it related somehow to Bug 68487? > > @Anyone who have this problem: Could you please run LO installation, > uninstall Shell extensions, and report if it solves the problem. Well done ! I've just tried it with 4.0.5 / Win 7 pro 64 bits Install with shell extension : bug "locked by unknown user" on network share Remove shell extension : same files opened without problem.
Yes, it works without SHELL-Extension... this is the problem...!! Th bug it is in Windows Explorer Extension.
(In reply to comment #51) > @Anyone who have this problem: Could you please run LO installation, > uninstall Shell extensions, and report if it solves the problem. I've tried it with LibreOffice 4.1.1, Windows 7 Pro 64bit, Synology DS110j NAS. Without the shell extension the files can be opened without a problem.
Tor had an idea what to do about the file locking, and proposed a fix, but we haven't actually reproduced the problem; if we can get feedback that master builds which include the commit actually fix the problem it can easily be backported to 4.0 and 4.1 release branches. but the last 4.0.6 branch will be tagged in a week or so, so needs quick feedback. daily builds of master available from here: http://dev-builds.libreoffice.org/daily/master/Win-x86@39/
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6cea76189fb8d9fbb358f757157df66c7ea31c85 fdo#67534: try to avoid file locking in Explorer shell extensions The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to comment #55) > if we can get feedback that master builds which include the > commit actually fix the problem it can easily be backported > to 4.0 and 4.1 release branches. but the last 4.0.6 branch will be > tagged in a week or so, so needs quick feedback. > > daily builds of master available from here: > http://dev-builds.libreoffice.org/daily/master/Win-x86@39/ @Michael Stahl: Unfortunately it's useless to test master builds, as desktop integration features (like file associations & shell extensions) are disabled there.
(In reply to comment #57) > @Michael Stahl: Unfortunately it's useless to test master builds, as desktop > integration features (like file associations & shell extensions) are > disabled there. according to jcorrius it is possible to install daily builds with system integration from command line: msiexec /i *.msi WRITE_REGISTRY=1
(In reply to comment #58) > (In reply to comment #57) > > @Michael Stahl: Unfortunately it's useless to test master builds, as desktop > > integration features (like file associations & shell extensions) are > > disabled there. > > according to jcorrius it is possible to install daily builds with > system integration from command line: > > msiexec /i *.msi WRITE_REGISTRY=1 I've just tried it with http://dev-builds.libreoffice.org/daily/master/Win-x86@39/2013-10-07_05.20.02/. Unfortunately the problem still exist in that version.
(In reply to comment #59) > I've just tried it with > http://dev-builds.libreoffice.org/daily/master/Win-x86@39/2013-10-07_05.20. > 02/. > Unfortunately the problem still exist in that version. Same here.
Same here too !
Same here, too. This bug is for me blocking, I am going to try some reverting commit. This one by example: http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a4c55f6d46aec5164ec2ec189ee39cf71c9308c
Mathieu - that commit isn't going do to anything :-) the best thing to do is to use the sysinternals process monitor from MS to see what takes & holds that lock. Having said that - I -suspect- that this is (perhaps) partly just a performance bug that I'm committing a fix for to master shortly. I'd love testing of a master build on windows that includes the fix for fdo#56007.
(In reply to comment #63) > Having said that - I -suspect- that this is (perhaps) partly just a > performance bug that I'm committing a fix for to master shortly. > > I'd love testing of a master build on windows that includes the fix for > fdo#56007. Well done! That fixes the problem for me. Tested with 4.2.0.0.alpha0+ Build ID: b60ce8465c8f01242354abccebe00742d164af60 TinderBox: Win-x86@39, Branch:master, Time: 2013-10-12_00:07:47
I've just tested this version: http://dev-builds.libreoffice.org/daily/master/Win-x86@39/2013-10-13_07.25.43/ It looks like the problem has been fixed in that version.
Hello, When I backport the commit in LO 4.0.5 I still have the bug. But when I test with the build version It seems that it has been resolved. Nevertheless I have reproduced it once.
Disabled windows explorer shell extensions in version 4.1.2.3 and I can now open the files using double click, so bug is somewhere in there.
Yes, this bug is also in Version 4.1.2.3 I have not use 4.2.0.0. alpha... work it correct or not?
The fix for bug 56007 reportedly fixed this bug, too.
*** Bug 67885 has been marked as a duplicate of this bug. ***
Bonjour, I have the same on a VNXE 3100 with CIFS shared folders. It does not work since 4.x, but OpenOffice 4 is OK and portable LibreOffce from http://portableapps.com/ is OK too !
*** Bug 68082 has been marked as a duplicate of this bug. ***
*** Bug 69568 has been marked as a duplicate of this bug. ***
*** Bug 71221 has been marked as a duplicate of this bug. ***
Created attachment 88813 [details] ODS File Save Error #1
Created attachment 88814 [details] ODS File Save Error #2
We have problems when saving to a network drive from a "Calc" document (.ods). At this stage we have, after many tests , with several different computers with different hardware but all running Windows Seven, determine that this problem occurs only in later versions of LibreOffice 4.0.5 , 4.0.6, 4.1.1 and 4.1.3 versions have been tested and we get the same message in 90% of cases as you can see in attachment (ODS File Save Error #1, ODS File Save Error #2). LibreOffice 4.0.4 works fine, we dont have any problem like that with this version, so currently we have to reinstall version 4.0.4 of LibreOffice to correct this problem. This file contains personal information and I am not able to communicate , I send you all the same some features of this Calc file: * It is composed of five sheets containing a few cells for the smallest to 5235 lines of 20 columns for the most important ; * The total volume is 768 KB ; The error occurs only when the larger and generally leaves is changed by opening the file by double-clicking from Windows Explorer , we determined that the error is less frequent opening the file from the file menu or from the recent LibreOffice LibreOffice files . Sincerely, Lionel Mourre
(In reply to comment #77) > this problem occurs only in later versions of LibreOffice 4.0.5 , 4.0.6, > 4.1.1 and 4.1.3 versions have been tested and we get the same message > in 90% of cases Hi, The fix for this bug will be included in 4.1.4, so please don't reopen it unless you can reproduce it with 4.1.4. In the meantime you have a workaround: run LibreOffice installation, choose 'Modify' and uncheck the installation of Windows Explorer extensions.
*** Bug 67389 has been marked as a duplicate of this bug. ***
*** Bug 71521 has been marked as a duplicate of this bug. ***
*** Bug 69123 has been marked as a duplicate of this bug. ***
*** Bug 72337 has been marked as a duplicate of this bug. ***
I wanted to let you know that I just found this information today and mine was similar, when I would attempt to save the same file I would sometimes get the same message. it would typically open, although sometimes it would not. I installed the 4.1.4 version and it seems to be working perfectly. I did multiple tests with Calc ODS files and did not get the message again. When I would save to a new name it would be fine, just not saving to the same name. Thank you.
I'm still getting this issue in 4.1.4. Pretty much any file I try to open on a Samba share gives me: "Document file 'blah.ods' is locked for editing by: Unknown User Open document read-only or open a copy of the document for editing.
Yi Ding - can you check whether there are hidden lock files left on your samba share for those files ? Failing that - as I said before - we need sysinternals' process-monitor installed, and a trace of the document saved as CSV that we can analyse here before we can get much further cf. http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx
Changed importance to reflect the new policy - Sophie
We found this problem within our rollout of Win7 and LibO4.x. It seems to have something to do with the little preview of the files in Win7 File-Explorer. If you klick on a filename ... and wait ... until the preview is complete, you could double-click the file and it opens without problems. If you double-click to fast, same procedure as written above. Our Workaround: de-activating the win7 preview-feature in our images. But it is only a workaround - I hope that this one could be fixed soon!!
comment #77 is for document export and probably has nothing to do with this bug, which is about opening files and the Explorer shell extension.
I have server samba Ubuntu, and clients windows 7 64. 1. In OpenOffice 4.1.5.3 double click on a file in explorer, file are used from a unknow user 2. If it is open this file in dialog of Libreoffce... it can open 3. In OpenOffice 4.0.3 work it correct
We seem to be suffering the same issue. libreoffice 4.2.3 rc 2 We are ending up with some ODT/ODS files opening but being unable to save due to a file lock on network drives only (CIFS/Server 2008). Most of the time the issue will only show when we try to save, sometimes the document will not open with a file already open dialogue on second+ attempt. these are more complex documents, with links etc. interestingly once they are locked, we cannot edit them on that machine even with a parallel install (done for testing) of AOO 4.01. It also only seems to affect ODF documents and not all of them (seems to be more complex ones of a fair file size) They behave again after a reboot of the affected system (not the server). It does seem to be tied to the use of windows explorer.
please retest against current 4.2.4.2 release. if issue is still there, please move it to mab4.2 list since 4.1.x is EOL
(In reply to comment #91) > please retest against current 4.2.4.2 release. > if issue is still there, please move it to mab4.2 list since 4.1.x is EOL I am in 4.2.4.2, and I can confirm that 1. double click on a file in explorer, file are used from a unknown user 2. If it is open this file in dialog of Libreoffce... it can open This two bugs still exist
moving to mab4.2, reverting status to NEW and version to 4.0.5.2 which is first release the bug appeared
Same Problem here. Our environment: - Client: Windows 7 64 Bit SP1 newest patch level - LibreOffice 4.2.4 - Server: Samba 3.6.19 on openSUSE 12.2 (tested with and without oplocks and kernel oplocks. These modifications have no influence in our case) A lot of comments here mentioned that the way off opening files (via explorer or direct from LO) makes a difference. Not in our case. I tried it with and without the LO Explorer Extensions, its always the same behavior. Strange on our situation is that it seems that this happens only on one workstation. ... and no there are no lock-files left on the server share. Stefan
Hello, guys. Same error here. Could you please confirm if the bug will be resolved in the next release of Libreoffice? Thanks a lot.
Please, do not change the version number which is intended to show the oldest version in which the bug has been encountered. Thank you for your understanding. Best regards. JBF
Still can reproduce this on Lbreoffice 4.3.0RC2 Win7 64bit, saving on a Windows Server. Meaning Save as... is possible, simple save leads to: "Error Saving the document ....: Access to ...was denied" Interestingly, it is not reproducible with every file. But 100% reproducible with the same file and all of its (involuntarily) made versions. The file I am having the problem with this time has embedded fonts (maybe this has something to do with it). Moreover, accessing the same file from my Laptop (Debian Wheezy 64bit, Libreoffice 4.1.6 64bit Deb released version from the Document Foundation Website, accessed over a mounted samba share) does not lead to the same problem (though subjectively the time it needs to save seems longer than expected)
I can confirm that this bug is still present for on LO 4.2.4.2 on a Win7 machine using files from a Samba share hosted on Ubuntu. Removing the shell extension solves the problem for me. As stated in comment #97, not all files as affected, but the bug is 100% reproducible for all affected files. Also, opening a file from within LO works without problem (even without removing shell extension). We do not experience any problems with LO 4.2.4.2 on Win8.
we found this bug after an update of a file server from centos 6.5 ext4 to centos 7 xfs. before the update we didn't have problems. The fileserver is exporting via nfs for linux and samba for windows. linux clients centos 6.5 libre office 4.0.4.2 and centos 7 libre office 4.1.4: files only on nfs directories are locked by unknown. it doesn't matter if the filename was provided by commandline or the open dialog menue was used. opening as copy and saving under new name leads to the creation of the file with 0 bytes of data and the error "Error during shared access to newfilename" on windows 2008 terminal server libre office 4.2.4.2: some of the files are opening by double clicking in explorer but leading to a crash on closing. most files are locked by root the same files are locked by root when opened in the open dialog menue. some files leading to crash of libre office upon double clicking. saving of file copies was possible on the network directory without error or zero byte files.
(In reply to comment #99) > we found this bug after an update of a file server from centos 6.5 ext4 to > centos 7 xfs. before the update we didn't have problems. > The fileserver is exporting via nfs for linux and samba for windows. > > linux clients centos 6.5 libre office 4.0.4.2 and centos 7 libre office > 4.1.4: > files only on nfs directories are locked by unknown. it doesn't matter if > the filename was provided by commandline or the open dialog menue was used. > opening as copy and saving under new name leads to the creation of the file > with 0 bytes of data and the error "Error during shared access to > newfilename" Can you run such a failing scenario from the command line (preferably with the newer LO 4.1.4) as strace -f soffice .../filename >LOG 2>&1 and make the resulting LOG file available?
I'am experiencing this issue with libreoffice 4.2.6 and 4.3.1 on windows 7 64 bits. My networks share is under windows SBS 2011, i'am able to open .xls and .rtf and write into here and save. But if i open an .ods or .odt i can see the message, the file is already open by unknown user. I was able to open the file sometimes, but if i made a change and hit save button, libreoffice save the error message : I/O error and then libreoffice crash.
(In reply to comment #100) > (In reply to comment #99) > > we found this bug after an update of a file server from centos 6.5 ext4 to > > centos 7 xfs. before the update we didn't have problems. > > The fileserver is exporting via nfs for linux and samba for windows. > > > > linux clients centos 6.5 libre office 4.0.4.2 and centos 7 libre office > > 4.1.4: > > files only on nfs directories are locked by unknown. it doesn't matter if > > the filename was provided by commandline or the open dialog menue was used. > > opening as copy and saving under new name leads to the creation of the file > > with 0 bytes of data and the error "Error during shared access to > > newfilename" > > Can you run such a failing scenario from the command line (preferably with > the newer LO 4.1.4) as > > strace -f soffice .../filename >LOG 2>&1 > > and make the resulting LOG file available? Received the log in private. It shows that F_SETLK requests on the given NFS mount always lead to ENOLCK, which needs to be addressed by unsetting the SAL_ENABLE_FILE_LOCKING variable in the soffice script, as detailed in the README accompanying LO (see quote below). Unfortunately, that does not shed any further light on this bug's original problem. > ---------------------------------------------------------------------- > File Locking > ---------------------------------------------------------------------- > > File locking is enabled by default in LibreOffice. On a network that uses the > Network File System protocol (NFS), the locking daemon for NFS clients must be > active. To disable file locking, edit the soffice script and change the line > "export SAL_ENABLE_FILE_LOCKING" to "# export SAL_ENABLE_FILE_LOCKING". If you > disable file locking, the write access of a document is not restricted to the > user who first opens the document.
Same here. Append on some computer but not all of them. It appears after an upgrade of our samba server to v3.6.6 (debian stable). Seems to be mixed with the green bar of doom in explorer. Try to open a file, sometimes OK, sometimes file is locked by unknow user, sometimes IO error. Every change made or request a save on a file cause windows7 to refresh the folder and forbid LO to save the file. Requesting multiples times a save can cause the file to be empty ! We need to wait for the green bar to complete in explorer. No problems under MSOffice or any other tool. I try turning off indexing, folder type on windows without success. Uninstall LO explorer extensions didn't help.
Same here. Append on some computers but not all of them. Using Windows 7 and LO 4.3.2.2, in a slow 400 Kb/s VPN network, a shared directory in an Active Directory 2003 environment. Append only with "bigs" files (1 Mb). It works fine with small files (12K). Append from Windows Explorer and also when I open files from LO. However I can sucessfully open files from explorer: - right click on file - waiting the green death IE bar fully displayed (contextual window still open) - open with > LibreOffice But LO display an error when I save the file. Antivirus disabled, Explorer preview disabled, drive indexing disabled and the problem still occurs.
I locked into this problem. It comes from the propertyhdl.dll and propertyhdl_x64.dll (in %programfiles%LibreOffice 4\program\shlxthdl). You can remove it and test. This dll is the property handler for open documents files : http://msdn.microsoft.com/en-us/library/windows/desktop/cc144125%28v=vs.85%29.aspx It happen on REALLY SLOW network shares but you can reproduce it with the help of windbg. It is only reproducible on Windows Vista or higher (XP doesn't support properties handlers). Process to reproduce (test on Windows 7 32) : * Install LO fresh (or master with WRITE_REGISTRY=1) * Install and configure WinDbg as describe in the wiki : https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg * launch LO * launch WinDbg * attach WinDbg to explorer.exe * breakpoint on CPropertyHdl::Initialize : bu propertyhdl!CPropertyHdl::Initialize * run : g * open the "Windows Explorer" and go to a folder where there is an odt file (or other Open Document) * clic on the odt file * WinDbg should breakpoint and the explorer be freezed * on the LO you launch earlier try to open the odt → "locked by unknow user" The test I already made : * With the explorer locked on propertyhdl!CPropertyHdl::Initialize : * LO can't open the odt : FAIL * MS Word can't open the odt : FAIL * WordPad can open the odt : OK * With the "Ideal Property Handler" ( http://msdn.microsoft.com/en-us/library/windows/desktop/dd940363%28v=vs.85%29.aspx#related_topics ) : * I built and installed this property handler * modified the registry to make the ideal dll start on odt files * LO can open the odt : OK * MS Word can open the odt : OK → A property handler should not "grab" the file and there is a problem with propertyhdl.dll * I also try to replace propertyhdl.dll by "ideal dll" but it doesn't work (WinDbg doesn't break on ::Initialize) * I also try to replace "ideal dll" by propertyhdl.dll but it doesn't work (WinDbg doesn't break on ::Initialize) I will continue to test and search for a solution but I am not a Windows specialist and some help would be appreciate.
Maxime, thanks, that is some good detective work! the problem is that when LO opens a file, it wants to have exclusive access to it and prevent another application / another user to edit the document at the same time, which is usually what you want to avoid 2 users overwriting each other's changes. when the shell extension has the file open, LO cannot get exclusive access and opening fails with ERROR_SHARING_VIOLATION. the propertyhdl shell extension basically needs to read the ZIP directory and the meta.xml stream of the document; this is usually 1K of data at the end and 8K at the beginning of the file - clearly it is not supposed to take a long time to read that... but perhaps there is a bug in the shell extension that leaves the file descriptor open for much longer than necessary?
Hello Michael, Thanks for your answer. (In reply to Michael Stahl from comment #106) > the problem is that when LO opens a file, it wants to have exclusive access > to it and prevent another application / another user to edit the document at > the same time, which is usually what you want to avoid 2 users overwriting > each other's changes. > > when the shell extension has the file open, LO cannot get exclusive access > and opening fails with ERROR_SHARING_VIOLATION. Yes, I got it. But the property handler is a read only one. It should open the file on "read only mode". ./shell/source/win32/shlxthandler/prophdl/propertyhdl.cxx HRESULT STDMETHODCALLTYPE CPropertyHdl::IsPropertyWritable(REFPROPERTYKEY /*key*/) { // We start with read only properties only return S_FALSE; } > the propertyhdl shell extension basically needs to read the ZIP directory > and the meta.xml stream of the document; this is usually 1K of data at the > end and 8K at the beginning of the file - clearly it is not supposed to take > a long time to read that... but perhaps there is a bug in the shell > extension that leaves the file descriptor open for much longer than > necessary? The problem only happens on REALLY SLOW network share… by "really slow" in mean a few Kb/s (I don't remember exactly how much but it was less than 56K). With such a bitrate reading the 9KB could take longer than an double clic to open the file.
according to some recent comments this bug still happens in recent 4.3.x releases, so I move this bug to mab4.3 list since 4.2.x is END OF LIFE
Hello, I found the problem. Solution is here : https://gerrit.libreoffice.org/#/c/13596/
http://cgit.freedesktop.org/libreoffice/core/commit/?id=25686bbcd2d39000640e2b9db835b5b4bea653c1
Maxime de Roucy committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=25686bbcd2d39000640e2b9db835b5b4bea653c1 fdo#67534 Fix "Property Handler" shared lock It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxime de Roucy committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=807e29cbf992ac8bdd7ae6e974bd72ea731d274c&h=libreoffice-4-4 fdo#67534 Fix "Property Handler" shared lock It will be available in 4.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Maxime de Roucy committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b25bef87eece6d5ed0492b374e5bf6cc4beefcbe&h=libreoffice-4-3 fdo#67534 Fix "Property Handler" shared lock It will be available in 4.3.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks so much for attention reaching this issue and solutions being applied!
@Maxim/Andras: As per comments 111-113 there have been commits for this bug, can we mark this one as resolved/fixed?
(In reply to Björn Michaelsen from comment #115) > @Maxim/Andras: As per comments 111-113 there have been commits for this bug, > can we mark this one as resolved/fixed? Yes, I think it can be marked as resolved/fixed. The patch is good theoretically. There has been no negative user feedback since then. This bug was very hard to reproduce, so I could not test it myself.
For a while now, I don't see the problem anymore. For me, it is solved. Thanks! Ivo