https://bugs.freedesktop.org/show_bug.cgi?id=59022
Priority: medium
Bug ID: 59022
Keywords: regression
Assignee: [email protected]
Summary: FILEOPEN general error (IOErrorCode_ACCESS_DENIED)
when opening file on CIFS filesystem
Severity: major
Classification: Unclassified
OS: Linux (All)
Reporter: [email protected]
Hardware: All
Status: UNCONFIRMED
Version: 4.0.0.0.beta2
Component: Writer
Product: LibreOffice
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
