Bug Hunting Session
Bug 67534 - FILEOPEN SMB File claimed to be "Locked By Unknown User" when opened via double-click in Explorer if LO Explorer Shell Extensions are installed
Summary: FILEOPEN SMB File claimed to be "Locked By Unknown User" when opened via doub...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.5.2 release
Hardware: Other Windows (All)
: highest major
Assignee: Andras Timar
URL:
Whiteboard: BSA target:4.2.0 target:4.1.4 target:...
Keywords: regression
: 67389 67885 68082 68757 69035 69123 69568 69770 71221 71521 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2013-07-30 12:34 UTC by Mike Silbermann
Modified: 2015-07-05 09:39 UTC (History)
36 users (show)

See Also:
Crash report or crash signature:


Attachments
Message if open with doubleclick in networkdrive (55.06 KB, image/jpeg)
2013-07-30 12:34 UTC, Mike Silbermann
Details
error if double click (54.71 KB, image/jpeg)
2013-09-17 08:17 UTC, Mike Silbermann
Details
ODS File Save Error #1 (12.96 KB, image/jpeg)
2013-11-07 09:13 UTC, Lionel M
Details
ODS File Save Error #2 (12.96 KB, image/jpeg)
2013-11-07 09:17 UTC, Lionel M
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Silbermann 2013-07-30 12:34:22 UTC
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
Comment 1 Urmas 2013-08-12 10:31:58 UTC
Is it a read-only share?
Comment 2 Mike Silbermann 2013-08-17 21:28:34 UTC
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.
Comment 3 Maxim Monastirsky 2013-08-19 15:45:02 UTC
Hi,
Could you please take a look at bug 67885 & bug 68082, Is it the same issue you have?
Comment 4 Mike Silbermann 2013-08-19 16:58:38 UTC
It could be the same problem under Umstaänden. But I'm not sure. OpenOffice 4.0.0 it works without problems, however.
Comment 5 Maxim Monastirsky 2013-08-19 17:16:03 UTC
(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?
Comment 6 Ivo 2013-08-23 10:29:13 UTC
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
Comment 7 Cor Nouws 2013-08-23 10:39:31 UTC
Note comment 6: the bug seems to have slipped in 4.0.5
Raised severity and added to MAB list.
Comment 8 Don't use this account, use tml@iki.fi 2013-08-23 10:47:01 UTC
@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?
Comment 9 Don't use this account, use tml@iki.fi 2013-08-23 11:04:17 UTC
Also the type of document might affect the behaviour, so what is it? .odt, .doc, .xlsx, etc?
Comment 10 Stephan Bergmann 2013-08-23 11:06:16 UTC
(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.)
Comment 11 Mike Silbermann 2013-08-23 11:36:02 UTC
No, i had find this problem only with odf - files
Comment 12 Mike Silbermann 2013-08-23 11:38:13 UTC
It could be the same problem under circumstances that are similar to the problems. I can see the problems with ODF files.
Comment 13 Cor Nouws 2013-08-23 13:37:03 UTC
hmm. a bug in the same area maybe, that seem to have been resolved around 4.0.4
  Bug 60961
Comment 14 Tor Lillqvist 2013-08-23 14:17:02 UTC
@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?
Comment 15 Cor Nouws 2013-08-23 16:04:52 UTC
(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 ..
Comment 16 Mike Silbermann 2013-08-23 19:07:29 UTC
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.
Comment 17 Tor Lillqvist 2013-08-23 19:15:37 UTC
@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.
Comment 18 Mike Silbermann 2013-08-23 19:24:04 UTC
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
Comment 19 Tor Lillqvist 2013-08-23 20:19:39 UTC
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.
Comment 20 Jared 2013-08-23 23:03:41 UTC
(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
Comment 21 Mike Silbermann 2013-08-24 07:53:48 UTC
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!
Comment 22 Cor Nouws 2013-08-24 08:37:51 UTC
@jared: when you added comment 20, the status and severity of this bug were changed to NEEDINFO and Normal.
Was that by intention?
Comment 23 Mike Silbermann 2013-08-24 09:04:28 UTC
No, it is a important error.... sorry!
Comment 24 Jared 2013-08-24 13:12:58 UTC
(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.
Comment 25 Cor Nouws 2013-08-24 15:46:22 UTC
(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.
Comment 26 David Schiebaan 2013-08-26 17:28:22 UTC
(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
Comment 27 Ivo 2013-09-01 09:38:03 UTC
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.
Comment 28 Nicolas R 2013-09-02 08:34:11 UTC
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
Comment 29 Cor Nouws 2013-09-02 08:43:56 UTC
*** Bug 68757 has been marked as a duplicate of this bug. ***
Comment 30 Mike Silbermann 2013-09-02 08:55:54 UTC
Yes, thats correct!
Comment 31 Nicolas R 2013-09-02 13:21:03 UTC
(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
Comment 32 Mike Silbermann 2013-09-02 14:39:09 UTC
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
Comment 33 Robin Edgar 2013-09-16 12:57:29 UTC
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
Comment 34 Robin Edgar 2013-09-16 12:58:40 UTC
- file also opens properly when using windows explorer, right click -> open with -> libreoffice writer
Comment 35 Mike Silbermann 2013-09-16 13:11:06 UTC
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.
Comment 36 Maxim Monastirsky 2013-09-16 20:00:07 UTC
@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.
Comment 37 Mike Silbermann 2013-09-16 21:07:44 UTC
Ok--- thats ok!
Comment 38 Mike Silbermann 2013-09-17 08:17:23 UTC
Created attachment 85948 [details]
error if double click

Here a actuel error sign of double-click
Comment 39 Nicolas R 2013-09-17 10:23:12 UTC
(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
Comment 40 Mike Silbermann 2013-09-17 14:04:53 UTC
4.0.4 it is ok...
Comment 41 Stephan Bergmann 2013-09-18 06:47:53 UTC
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.
Comment 42 Fridrich Strba 2013-09-18 07:07:06 UTC
(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.
Comment 43 Maxim Monastirsky 2013-09-21 19:08:07 UTC
*** Bug 69035 has been marked as a duplicate of this bug. ***
Comment 44 bureautiquelibre 2013-09-23 14:34:30 UTC
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.
Comment 45 Jean-Baptiste Faure 2013-09-26 10:59:27 UTC
Due to several comments, changed version for the earliest where users experienced the bug: 4.0.5

Best regards. JBF
Comment 46 Maxim Monastirsky 2013-09-26 20:13:01 UTC
*** Bug 69770 has been marked as a duplicate of this bug. ***
Comment 47 Jean-Baptiste Faure 2013-09-27 13:35:39 UTC
This bug is in MAB4.1 but it affects LO 4.0.5 too. Should it be moved to MAB4.0 ?

Best regards. JBF
Comment 48 Luuk 2013-09-27 18:01:59 UTC
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)
Comment 49 Luuk 2013-09-27 18:25:04 UTC
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",
Comment 50 Mike Silbermann 2013-09-28 09:26:25 UTC
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...
Comment 51 Maxim Monastirsky 2013-09-28 18:02:15 UTC
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.
Comment 52 Nicolas R 2013-09-30 08:06:43 UTC
(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.
Comment 53 Mike Silbermann 2013-10-02 09:31:40 UTC
Yes, it works without SHELL-Extension... this is the problem...!! Th bug it is in Windows Explorer Extension.
Comment 54 Christian 2013-10-03 07:18:02 UTC
(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.
Comment 55 Michael Stahl (CIB) 2013-10-04 19:43:13 UTC
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/
Comment 56 Commit Notification 2013-10-04 19:49:20 UTC
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.
Comment 57 Maxim Monastirsky 2013-10-06 12:10:44 UTC
(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.
Comment 58 Michael Stahl (CIB) 2013-10-07 13:50:26 UTC
(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
Comment 59 Christian 2013-10-07 19:39:12 UTC
(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.
Comment 60 Maxim Monastirsky 2013-10-08 05:38:09 UTC
(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.
Comment 61 Nicolas R 2013-10-09 19:11:37 UTC
Same here too !
Comment 62 Matthieu 2013-10-10 14:00:32 UTC
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
Comment 63 Michael Meeks 2013-10-11 16:47:18 UTC
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.
Comment 64 Maxim Monastirsky 2013-10-13 05:47:53 UTC
(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
Comment 65 Christian 2013-10-13 18:13:18 UTC
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.
Comment 66 Matthieu 2013-10-15 11:14:22 UTC
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.
Comment 67 Robin Edgar 2013-10-16 09:55:28 UTC
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.
Comment 68 Mike Silbermann 2013-10-16 14:36:28 UTC
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?
Comment 69 Andras Timar 2013-10-25 09:18:29 UTC
The fix for bug 56007 reportedly fixed this bug, too.
Comment 70 Maxim Monastirsky 2013-10-25 10:36:29 UTC
*** Bug 67885 has been marked as a duplicate of this bug. ***
Comment 71 Olivier MORIN 2013-10-28 11:38:04 UTC
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 !
Comment 72 Maxim Monastirsky 2013-10-28 15:46:36 UTC
*** Bug 68082 has been marked as a duplicate of this bug. ***
Comment 73 Maxim Monastirsky 2013-11-02 17:11:00 UTC
*** Bug 69568 has been marked as a duplicate of this bug. ***
Comment 74 bfoman (inactive) 2013-11-05 16:57:11 UTC
*** Bug 71221 has been marked as a duplicate of this bug. ***
Comment 75 Lionel M 2013-11-07 09:13:08 UTC
Created attachment 88813 [details]
ODS File Save Error #1
Comment 76 Lionel M 2013-11-07 09:17:38 UTC
Created attachment 88814 [details]
ODS File Save Error #2
Comment 77 Lionel M 2013-11-07 09:26:48 UTC
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
Comment 78 Maxim Monastirsky 2013-11-07 11:27:52 UTC
(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.
Comment 79 Jean-Baptiste Faure 2013-11-13 05:30:06 UTC
*** Bug 67389 has been marked as a duplicate of this bug. ***
Comment 80 Julien Nabet 2013-11-13 06:36:27 UTC
*** Bug 71521 has been marked as a duplicate of this bug. ***
Comment 81 Maxim Monastirsky 2013-11-16 18:52:23 UTC
*** Bug 69123 has been marked as a duplicate of this bug. ***
Comment 82 bfoman (inactive) 2013-12-05 17:22:50 UTC
*** Bug 72337 has been marked as a duplicate of this bug. ***
Comment 83 Stephen Kovacsiss 2013-12-09 01:23:53 UTC
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.
Comment 84 Yi Ding 2013-12-26 18:59:44 UTC
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.
Comment 85 Michael Meeks 2013-12-28 14:10:46 UTC
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
Comment 86 sophie 2014-02-12 09:48:01 UTC
Changed importance to reflect the new policy - Sophie
Comment 87 M. Hoffmann 2014-03-07 13:21:37 UTC
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 88 Michael Stahl (CIB) 2014-03-07 13:35:55 UTC
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.
Comment 89 Valentin 2014-03-27 10:12:35 UTC
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
Comment 90 eamonfitzpatrick 2014-04-04 09:17:32 UTC
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.
Comment 91 tommy27 2014-05-12 19:08:07 UTC
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
Comment 92 foray1010 2014-05-14 02:36:58 UTC
(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
Comment 93 tommy27 2014-05-14 03:28:24 UTC
moving to mab4.2, reverting status to NEW and version to 4.0.5.2 which is first release the bug appeared
Comment 94 Stefan Schäfer 2014-05-15 10:16:13 UTC
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
Comment 95 Marco 2014-06-18 13:01:43 UTC
Hello, guys.

Same error here.

Could you please confirm if the bug will be resolved in the next release of Libreoffice?

Thanks a lot.
Comment 96 Jean-Baptiste Faure 2014-06-18 18:36:28 UTC
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
Comment 97 Nikos 2014-07-14 13:40:46 UTC
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)
Comment 98 daniel 2014-08-18 11:06:54 UTC
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.
Comment 99 campher 2014-09-17 17:58:24 UTC
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.
Comment 100 Stephan Bergmann 2014-09-18 06:44:06 UTC
(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?
Comment 101 xillibit 2014-09-19 15:29:40 UTC
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.
Comment 102 Stephan Bergmann 2014-09-22 14:39:56 UTC
(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.
Comment 103 grimomatieu 2014-09-22 14:42:06 UTC
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.
Comment 104 Guillaume Fillol 2014-10-16 13:30:01 UTC
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.
Comment 105 Maxime de Roucy 2014-10-21 13:07:52 UTC
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.
Comment 106 Michael Stahl (CIB) 2014-10-21 13:38:54 UTC
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?
Comment 107 Maxime de Roucy 2014-10-22 12:31:04 UTC
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.
Comment 108 tommy27 2014-11-30 18:14:04 UTC
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
Comment 109 Maxime de Roucy 2015-01-05 08:39:11 UTC
Hello,

I found the problem.
Solution is here : https://gerrit.libreoffice.org/#/c/13596/
Comment 111 Commit Notification 2015-02-03 11:54:55 UTC
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.
Comment 112 Commit Notification 2015-02-03 12:02:21 UTC
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.
Comment 113 Commit Notification 2015-02-03 12:58:30 UTC
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.
Comment 114 Jared 2015-02-03 16:51:09 UTC
Thanks so much for attention reaching this issue and solutions being applied!
Comment 115 Björn Michaelsen 2015-07-05 01:23:32 UTC
@Maxim/Andras: As per comments 111-113 there have been commits for this bug, can we mark this one as resolved/fixed?
Comment 116 Andras Timar 2015-07-05 08:39:42 UTC
(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.
Comment 117 Ivo 2015-07-05 09:39:24 UTC
For a while now, I don't see the problem anymore. For me, it is solved.

Thanks!
Ivo