Bug 59022 - FILEOPEN general error (IOErrorCode_ACCESS_DENIED) when opening OpenDocument file on CIFS filesystem
Summary: FILEOPEN general error (IOErrorCode_ACCESS_DENIED) when opening OpenDocument ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta2
Hardware: All Linux (All)
: medium major
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:4.1.0 target:4.0.1
Keywords: regression
: 61267 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-01-04 13:03 UTC by Lionel Elie Mamane
Modified: 2013-10-15 13:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-01-04 13:03:38 UTC
When opening an .odt file on a CIFS filesystem (share from a Windows computer), an error dialog saying "General Error" appears and the file is not opened.

From gdb, with "catch throw", I see:

(gdb) up
#6  0x00007f71569b3a02 in ucbhelper::cancelCommandExecution (eError=com::sun::star::ucb::IOErrorCode_ACCESS_DENIED, 
    rArgs=uno::Sequence of length 3 = {...}, xEnv=empty uno::Reference, rMessage="general error during transfer", xContext=
    uno::Reference to {
  <com::sun::star::uno::XInterface> = {
    _vptr.XInterface = 0x7f71416ae130
  }, <No data fields>}) at /home/master/src/libreoffice/workdirs/libreoffice-4.0/ucbhelper/source/provider/cancelcommandexecution.cxx:112

and indeed from a shell:

$ cat filename.odt
cat: filename.odt: Permission denied

*but* as soon as I do "continue" in gdb and click away the error dialog, the above "cat" command succeeds!

So it seems LibreOffice somehow tries to open the file twice and keeps itself from doing it (!) through some kind of lock.

Here's what an strace shows:

8679  lstat("/path/to/filename.odt",  <unfinished ...>
8679  <... lstat resumed> {st_mode=S_IFREG|0600, st_size=32957, ...}) = 0
8550  access("/path/to/filename.odt", F_OK) = 0
8550  lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=32957, ...}) = 0
8550  open("/path/to/filename.odt", O_RDWR|O_EXCL) = 65
8550  fstat(65, {st_mode=S_IFREG|0600, st_size=32957, ...}) = 0
8550  fcntl(65, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0

I notice the open is with "O_RDWR|O_EXCL". "man 2 open" says:

 The behavior of O_EXCL is undefined if O_CREAT is not specified.

So LibreOffice should not do that!!!

Then, LibreOffice acquires a fcntl exclusive write-lock on the *whole* file (len=0 has the special meaning: until the end of the file).

Then it does several consecutive pread calls on the file, several of which are REDUNDANT:

8550  time(NULL)                        = 1357298553
8550  time(NULL)                        = 1357298553
8550  pread(65, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
8550  pread(65, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
8550  pread(65, "h\0162\345\3K\351\2Y\30\6Sp\331\352\205\202\311\215\343\36@\303K\201\22\6\241TzHM"..., 4096, 28672) = 4096
8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"..., 4096, 32768) = 189
8550  pread(65, "h\0162\345\3K\351\2Y\30\6Sp\331\352\205\202\311\215\343\36@\303K\201\22\6\241TzHM"..., 4096, 28672) = 4096
8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"..., 4096, 32768) = 189
8550  pread(65, "h\0162\345\3K\351\2Y\30\6Sp\331\352\205\202\311\215\343\36@\303K\201\22\6\241TzHM"..., 4096, 28672) = 4096
8550  time(NULL)                        = 1357298553
8550  pread(65, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096

It calls:
 pread(65,, 4096, 0) THREE TIMES
 pread(65,, 4096, 28672) THREE TIMES
 pread(65,, 4096, 32768) TWO TIMES

a bit later:

8550  access("/path/to/filename.odt", F_OK) = 0
8550  access("/path/to/filename.odt", F_OK) = 0
8550  lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=32957, ...}) = 0

(two consecutive calls the access()...)

later it creates its lockfile:

8550  open("/path/to/.~lock.filename.odt#", O_RDONLY|O_EXCL) = -1 ENOENT (No such file or directory)
8550  open("/path/to/.~lock.filename.odt#", O_RDWR|O_CREAT|O_EXCL, 0666) = 69

a few more times access && lstat on the file... and finally it opens the file a second time:

8550  open("/path/to/filename.odt", O_RDONLY) = 68
8550  fstat(68, {st_mode=S_IFREG|0600, st_size=32957, ...}) = 0
8550  open("/tmp/luj8dx80.tmp/luj8dxdw.tmp", O_WRONLY|O_CREAT, 0100600) = 69
8550  pread(68, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 32767, 0) = 8192
8550  write(69, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 8192) = 8192
8550  pread(68, 0x7fff93aa7850, 24765, 8192) = -1 EACCES (Permission denied)
550  close(68)                         = 0

I'm unsure why the first pread call there succeeds, since the fcntl call locks the whole file; maybe this is some bug/imperfection in the Linux CIFS FS or the Windows file server lock this fcntl() call maps to. Anyway, the second pread call fails, as should be the case, because of the fcntl lock.

LibreOffice then reads from and writes to the file from the first (R/W) fd (again in redundant ways...):

pread(65, "WQ'\212\n\305\3D\250n\351\31\341\22\221\35\252\323\374\236\351\232\223Nt\2752\232\6\352\304\352"..., 4096, 4096) = 4096
8550  pwrite(65, "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 8192, 0) = 8192
8550  pread(65,  <unfinished ...>
8550  pwrite(65, "\253\334\7aQ\230\30\30H\5v\1\261L\351\243lr\22O6\2716d\375\240\t\232\225\302EP"..., 8192, 8192) = 8192
8550  pread(65, "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\376(\n>"..., 8192, 16384) = 8192
8550  pwrite(65, "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\376(\n>"..., 8192, 16384) = 8192
8550  pread(65, "y! \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265K\32\215R\232"..., 8192, 24576) = 8192
8550  pwrite(65, "y! \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265K\32\215R\232"..., 8192, 24576) = 8192
8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"..., 8192, 32768) = 189
8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"..., 4096, 32768) = 189

And that's the last trace I find of this file in the strace.

My own libreoffice-4-0 debug build. "make clean && make dev-install" does not solve the issue, neither does moving the profile directory (~/.config/libreoffice/4) away.

My own debug build of libreoffice-3-6 does not have this behaviour, neither did my debug build of libreoffice-4-0 before today's pull/merge/rebuild.
Comment 1 Lionel Elie Mamane 2013-01-04 13:05:55 UTC
The error dialog very exactly says:

General Error.
General input/output error.
Comment 2 Lionel Elie Mamane 2013-01-04 13:10:31 UTC
This problem is specific to .odt files and does not happen with .doc or .txt files.
Comment 3 Lionel Elie Mamane 2013-01-04 13:11:27 UTC
If file is copied to a local filesystem, it works well and this bug does not appear.
Comment 4 Lionel Elie Mamane 2013-01-04 13:18:09 UTC
This patch resolves the issue, removing the fcntl call:


--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -1033,7 +1033,7 @@ SAL_CALL osl_openFilePath( const char *cpFilePath, oslFileHandle* pHandle, sal_u
             aflock.l_start = 0;
             aflock.l_len = 0;
 
-            if (-1 == fcntl (fd, F_SETLK, &aflock))
+            if (-1 == 0)
             {
                 int saved_errno = errno;
                 OSL_TRACE("osl_openFile(%s, %s): fcntl(%d, F_SETLK) failed: %s",


It probably breaks other things and is not the right fix, but it confirms that the culprit is the fcntl call in the strace and the "idea" of opening the file twice!
Comment 5 Michael Meeks 2013-01-10 10:21:25 UTC
Hi Lionel - thanks for the great debugging here ! :-)

Opening a file multiple times and fiddling with it is really par for the course :-) in general, we only worry about it if there is a demonstrable performance problem coming from it.

Anyhow - in this case, I guess we need to get two stack-traces: of the first time the file is opened, and the second - I imagine the first one should be closed before the second is opened: at least if they're both exclusive ;-) presumably something subtle changed there.

Any chance of a pair of traces of that with symbols ? :-)

Thanks !
Comment 6 Lionel Elie Mamane 2013-01-14 10:03:26 UTC
Reproduced with .ods file (OpenDocument spreadsheet).

Will try to provide the requested backtraces in a few days.
Comment 7 Michael Stahl (CIB) 2013-01-16 23:20:20 UTC
i've fixed something related in 0c2206081de38a41597aadfb2255540d6308be63
but that one struck on WNT only...

trying it with a local file i get first open from type detection
filling the XInputStream in the Media Descriptor:

#0  open64 () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f1a5cb64740 in osl_openFilePath (cpFilePath=0x7fff7845bb50 "/Documents/RGBA PNG.odt", pHandle=0x305e8e0, uFlags=3) at /master/sal/osl/unx/file.cxx:914
...
#10 0x00007f1a5919dd38 in ucbhelper::Content::openWriteableStream (this=0x7fff7845d0a0) at /master/ucbhelper/source/client/content.cxx:765
#11 0x00007f1a5c44fe10 in comphelper::MediaDescriptor::impl_openStreamWithURL (this=0x7fff7845d7d0, sURL="file:///Documents/RGBA%20PNG.odt", bLockFile=1 '\001') at /master/comphelper/source/misc/mediadescriptor.cxx:610
#12 0x00007f1a5c44efdb in comphelper::MediaDescriptor::impl_addInputStream (this=0x7fff7845d7d0, bLockFile=1 '\001') at /master/comphelper/source/misc/mediadescriptor.cxx:469
#13 0x00007f1a5c44ec66 in comphelper::MediaDescriptor::addInputStreamOwnLock (this=0x7fff7845d7d0) at /master/comphelper/source/misc/mediadescriptor.cxx:435
#14 0x00007f1a3f586b3b in filter::config::TypeDetection::impl_openStream (this=0x299e710, rDescriptor=...) at /master/filter/source/config/cache/typedetection.cxx:1184
#15 0x00007f1a3f5861eb in filter::config::TypeDetection::impl_askDetectService (this=0x299e710, sDetectService="com.sun.star.text.FormatDetector", rDescriptor=...) at /master/filter/source/config/cache/typedetection.cxx:1029
Traceback (most recent call last):
  File "/lib64/../share/gcc-4.7.2/python/libstdcxx/v6/printers.py", line 103, in children
    nodetype = find_type(self.val.type, '_Node')
  File "/lib64/../share/gcc-4.7.2/python/libstdcxx/v6/printers.py", line 43, in find_type
    field = typ.fields()[0]
IndexError: list index out of range
#16 0x00007f1a3f584cc2 in filter::config::TypeDetection::impl_detectTypeFlatAndDeep (this=0x299e710, rDescriptor=..., lFlatTypes=std::__debug::list, bAllowDeep=1 '\001', rUsedDetectors=..., rLastChance="") at /master/filter/source/config/cache/typedetection.cxx:836
#17 0x00007f1a3f5822f4 in filter::config::TypeDetection::queryTypeByDescriptor (this=0x299e710, lDescriptor=uno::Sequence of length 7 = {...}, bAllowDeep=1 '\001') at /master/filter/source/config/cache/typedetection.cxx:296
#18 0x00007f1a47fb4fee in framework::LoadEnv::impl_detectTypeAndFilter (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:796
#19 0x00007f1a47fb3782 in framework::LoadEnv::startLoading (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:382
#20 0x00007f1a47f38754 in framework::LoadDispatcher::impl_dispatch (this=0x2d22bf0, rURL=..., lArguments=uno::Sequence of length 3 = {...}, xListener=empty uno::Reference) at /master/framework/source/dispatch/loaddispatcher.cxx:119


second open is then to copy the file to a temp-file in SfxMedium:

#0  open64 () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f1a5cb64740 in osl_openFilePath (cpFilePath=0x7fff78459810 "/Documents/RGBA PNG.odt", pHandle=0x7fff78458698, uFlags=41) at /master/sal/osl/unx/file.cxx:914
...
#14 0x00007f1a5919f38e in ucbhelper::Content::transferContent (this=0x7fff7845cb30, rSourceContent=..., eOperation=ucbhelper::InsertOperation_COPY, rTitle="lu10khfm.tmp", nNameClashAction=1, rMimeType="application/vnd.oasis.opendocument.text", bMajorVersion=false, rVersionComment="", pResultURL=0x0) at /master/ucbhelper/source/client/content.cxx:1030
#15 0x00007f1a5b066d85 in SfxMedium::CreateTempFile (this=0x2d87e30, bReplace=0 '\000') at /master/sfx2/source/doc/docfile.cxx:3343
#16 0x00007f1a5b05c224 in SfxMedium::GetStorage (this=0x2d87e30, bCreateTempIfNo=1 '\001') at /master/sfx2/source/doc/docfile.cxx:1254
#17 0x00007f1a5b0d02f0 in SfxObjectShell::DoLoad (this=0x2873360, pMed=0x2d87e30) at /master/sfx2/source/doc/objstor.cxx:637
#18 0x00007f1a5b115f1a in SfxBaseModel::load (this=0x3052940, seqArguments=uno::Sequence of length 14 = {...}) at /master/sfx2/source/doc/sfxbasemodel.cxx:1878
#19 0x00007f1a5b17b7fb in SfxFrameLoader_Impl::load (this=0x2f11520, rArgs=uno::Sequence of length 13 = {...}, _rTargetFrame=uno::Reference to {
  <com::sun::star::lang::XComponent> = {
    <com::sun::star::uno::XInterface> = {
      _vptr.XInterface = 0x7f1a48507430
    }, <No data fields>}, <No data fields>}) at /master/sfx2/source/view/frmload.cxx:598
#20 0x00007f1a47fb71eb in framework::LoadEnv::impl_loadContent (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:1151
#21 0x00007f1a47fb37c7 in framework::LoadEnv::startLoading (this=0x2d22c88) at /master/framework/source/loadenv/loadenv.cxx:399
#22 0x00007f1a47f38754 in framework::LoadDispatcher::impl_dispatch (this=0x2d22bf0, rURL=..., lArguments=uno::Sequence of length 3 = {...}, xListener=empty uno::Reference) at /master/framework/source/dispatch/loaddispatcher.cxx:119


... no idea what to do about it, other than perhaps to somehow use the
Media Descriptor stream to create the temp file?

i wonder why that used to work in older versions then?
Comment 8 Lionel Elie Mamane 2013-01-17 04:20:12 UTC
(In reply to comment #7)

> trying it with a local file i get first open from type detection
> filling the XInputStream in the Media Descriptor:

> second open is then to copy the file to a temp-file in SfxMedium:

> ... no idea what to do about it, other than perhaps to somehow use the
> Media Descriptor stream to create the temp file?

Or close the Media Descriptor stream before creating the temp file? Or think again why we need a lock?

> i wonder why that used to work in older versions then?

Here's the difference I see from the strace: In older versions, the first opened file is not read from before opening the second file. Possibly the lock that is taken is "lazy", as in it is gotten only when actually reading/writing data from/to the file?

Actually, the first opened file is *never* read from. So it seems the "XInputStream in the Media Descriptor" is never used in older versions. So my guess is that something changed in type detection, or maybe XInputStream is less lazy?

First open (presumed to be type detection)

27360 access("/path/to/filename.odt", F_OK) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/path/to/filename.odt", O_RDWR|O_EXCL) = 33
27360 fstat(33, {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 fcntl(33, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0

Then a weird dance is done where the lockfile is created as a temporary file and then copied to the actual lockfile (why not write directly to the lockfile?)

27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", O_RDWR|O_EXCL) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
27360 fcntl(36, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 pread(36, "", 4096, 0)            = 0
27360 pwrite(36, ",master,camp.domain.gestman.lu,1"..., 90, 0) = 90
27360 close(36)                         = 0
27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", O_RDWR|O_EXCL) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=90, ...}) = 0
27360 fcntl(36, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
27360 open("/path/to/.~lock.filename.odt#", O_RDONLY|O_EXCL) = -1 ENOENT (No such file or directory)
27360 open("/path/to/.~lock.filename.odt#", O_RDWR|O_CREAT|O_EXCL, 0666) = 63
27360 fstat(63, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
27360 pread(36, ",master,camp.domain.gestman.lu,1"..., 32768, 0) = 90
27360 close(36)                         = 0
27360 pread(63, "", 4096, 0)            = 0
27360 pwrite(63, ",master,camp.domain.gestman.lu,1"..., 90, 0) = 90
27360 close(63)                         = 0
27360 lstat("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp", {st_mode=S_IFREG|0600, st_size=90, ...}) = 0
27360 unlink("/tmp/lu1d2lc5.tmp/lu1d2lh1.tmp") = 0

Second open, and read/write:

27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 access("/tmp/lu1d2lc5.tmp", F_OK) = 0
27360 lstat("/tmp/lu1d2lc5.tmp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
27360 access("/path/to/filename.odt", F_OK) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/path/to/filename.odt", O_RDONLY) = 36
27360 fstat(36, {st_mode=S_IFREG|0600, st_size=42388, ...}) = 0
27360 open("/tmp/lu1d2lc5.tmp/lu1d2lh2.tmp", O_WRONLY|O_CREAT, 0100600) = 63
27360 pread(36, "PK\3\4\24\0\0\10\0\0zC+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 32767, 0) = 32767
27360 write(63, "PK\3\4\24\0\0\10\0\0zC+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 32767) = 32767
27360 pread(36, "\0245\356v\347:|<\242\314\304\343\243(+\3235K~\313\265\226}\342\245\240yN\245\323}\320"..., 9621, 32767) = 9621
27360 write(63, "\0245\356v\347:|<\242\314\304\343\243(+\3235K~\313\265\226}\342\245\240yN\245\323}\320"..., 9621) = 9621
27360 close(36)                         = 0
27360 close(63)                         = 0
Comment 9 Lionel Elie Mamane 2013-01-17 04:34:55 UTC
I just discovered that I get the problem only on *some* files. Here's what an strace looks on a file that works in 4.0:

27598 access("/path/to/filename.odt", F_OK) = 0
27598 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=2914
27598 access("/path/to/filename.odt", F_OK) = 0
27598 lstat("/path/to/filename.odt", {st_mode=S_IFREG|0600, st_size=2914
27598 open("/path/to/filename.odt", O_RDONLY|O_EXCL) = 67
27598 fstat(67, {st_mode=S_IFREG|0600, st_size=29142, ...}) = 0
27598 pread(67, "PK\3\4\24\0\0\10\0\0!K+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 pread(67, "\0\0Configurations2/toolbar/PK\1\2\24\0"..., 4096, 28672) = 470
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 pread(67, "\0\0Configurations2/toolbar/PK\1\2\24\0"..., 4096, 28672) = 470
27598 pread(67, " \221\201@\215\tL\312\204t\203\34\272NK\3053\226\363Q9\301\241\355\342\307`\275\323\203\242<"..., 4096, 24576) = 4096
27598 time(NULL)                        = 1358397004
27598 pread(67, "PK\3\4\24\0\0\10\0\0!K+B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 4096, 0) = 4096
27598 close(67)                         = 0



Here, the "type detection" file open is *closed* before proceeding to the "copy to temporary file", thus freeing the lock.
Comment 10 Lionel Elie Mamane 2013-01-17 05:04:25 UTC
(In reply to comment #0)
> LibreOffice then reads from and writes to the file from the first (R/W) fd:
> 
> pread(65,
> "WQ'\212\n\305\3D\250n\351\31\341\22\221\35\252\323\374\236\351\232\223Nt\275
> 2\232\6\352\304\352"..., 4096, 4096) = 4096
> 8550  pwrite(65,
> "PK\3\4\24\0\0\10\0\0\224P$B^\3062\f'\0\0\0'\0\0\0\10\0\0\0mi"..., 8192, 0)
> = 8192
> 8550  pread(65,  <unfinished ...>
> 8550  pwrite(65,
> "\253\334\7aQ\230\30\30H\5v\1\261L\351\243lr\22O6\2716d\375\240\t\232\225\302
> EP"..., 8192, 8192) = 8192
> 8550  pread(65,
> "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\
> 376(\n>"..., 8192, 16384) = 8192
> 8550  pwrite(65,
> "\212E\323\t\245\210A\306\316P\333\202\5\v\304\32X[\374zk\25\337\355\f\325R9\
> 376(\n>"..., 8192, 16384) = 8192
> 8550  pread(65, "y!
> \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265
> K\32\215R\232"..., 8192, 24576) = 8192
> 8550  pwrite(65, "y!
> \270\212E*\224(\245\352\216\31\366?\324\315t\240\222\333\253D\335\322\342\265
> K\32\215R\232"..., 8192, 24576) = 8192
> 8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"...,
> 8192, 32768) = 189
> 8550  pread(65, "ons2/statusbar/PK\1\2\24\0\24\0\10\10\10\0\224P$B\0"...,
> 4096, 32768) = 189

It seems to be essentially copying the file to itself (!). So possibly there is some mixup somewhere between "temporary file" and "original file".

Note that this is annoying as behaviour, because it updates the file's "last modified" timestamp when merely opening the file (no change, no save).

Also, it seems to be linked to this bug. When opening the file succeeds, its "last modified" timestamps is *NOT* changed.
Comment 11 Michael Stahl (CIB) 2013-01-17 11:26:08 UTC
(In reply to comment #8)
> (In reply to comment #7)
> 
> > trying it with a local file i get first open from type detection
> > filling the XInputStream in the Media Descriptor:
> 
> > second open is then to copy the file to a temp-file in SfxMedium:
> 
> > ... no idea what to do about it, other than perhaps to somehow use the
> > Media Descriptor stream to create the temp file?
> 
> Or close the Media Descriptor stream before creating the temp file? Or think
> again why we need a lock?

this whole SfxMedium stuff is rather complex and i don't understand
much of it anyway...

> > i wonder why that used to work in older versions then?
> 
> Here's the difference I see from the strace: In older versions, the first
> opened file is not read from before opening the second file. Possibly the
> lock that is taken is "lazy", as in it is gotten only when actually
> reading/writing data from/to the file?
> 
> Actually, the first opened file is *never* read from. So it seems the
> "XInputStream in the Media Descriptor" is never used in older versions. So
> my guess is that something changed in type detection, or maybe XInputStream
> is less lazy?

interesting. what happens if you revert
0c2206081de38a41597aadfb2255540d6308be63 ?
Comment 12 Lionel Elie Mamane 2013-01-17 12:56:43 UTC
(In reply to comment #11)
> (In reply to comment #8)
>> (In reply to comment #7)

>>> i wonder why that used to work in older versions then?

>> Here's the difference I see from the strace: In older versions, (...)
>> the first opened file is *never* read from. So it seems the
>> "XInputStream in the Media Descriptor" is never used in older versions.

> interesting. what happens if you revert
> 0c2206081de38a41597aadfb2255540d6308be63 ?

This bug disappears.
Comment 13 Michael Stahl (CIB) 2013-01-17 13:00:33 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > interesting. what happens if you revert
> > 0c2206081de38a41597aadfb2255540d6308be63 ?
> 
> This bug disappears.

so we can choose between locking problems on Windows and locking problems on Linux... life is awesome :)
Comment 14 Not Assigned 2013-01-31 22:52:54 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0799130b0ba954715d00feb93cef83dd48e29889

fdo#59022: revert "SfxMedium::GetOutputStream(): re-use existing XStream"



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 15 Michael Stahl (CIB) 2013-01-31 23:02:20 UTC
so i've decided to revert the SfxMedium change for now;
the unit test that didn't work on Windows used different filter flags
than the actual LO.

this should hopefully fix things according to comment #12.
Comment 16 Lionel Elie Mamane 2013-02-01 07:15:46 UTC
Awaiting review for backport to 4.0.1: https://gerrit.libreoffice.org/#/c/1952/
Comment 17 Lionel Elie Mamane 2013-02-01 07:33:57 UTC
On Fri, Feb 01, 2013 at 07:11:06AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=59022

> Lionel Elie Mamane <lionel@mamane.lu> changed:

>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jmadero.dev@gmail.com

Since you mentioned you were looking for Samba-related bugs, I bring
this one to your attention. Fixed in master (4.1).
Comment 18 Not Assigned 2013-02-02 16:54:17 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6523f78456c9f78fb842b7215eb84a96f4e92472&h=libreoffice-4-0

fdo#59022: revert "SfxMedium::GetOutputStream(): re-use existing XStream"


It will be available in LibreOffice 4.0.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 19 lars.luennemann 2013-02-25 08:52:40 UTC
*** Bug 61267 has been marked as a duplicate of this bug. ***