Issue 105224

Sorry, have to fix priority: Until now we could "only" observe lost of data
(enterd by the one who not saved last), the file was not corrupted; at least
until now ;-)

confirmed with OOo 3.1.1 

this also happens with samba as fileserver, without nobrl option andcan easily
be verified using a mixe OOo 3.1.1 / 2.4 environment.

Seems, as if the implementation of issue 95809 was brocken in 3.1.1 again. I'm
going to set up and describe some more szenarios.

@mav/tm:
The spec for issue 95809 referes to some "invisible option" to turn off system
file locking - but does not name the option. Can you say, wht option this is?

I suspect that the system file locking just does not work in this configuration. 

To check it, please try to open the document with OOo2.4 from the mentioned
Linux client and with MS-Office from the Windows client.

sorry, did not state this yet - the same scenario worked in 3.1.0
(not perfectly, as I got an "I/O" error on my system, but at least the files
were locked)

Not reproducible when executing following steps:

- using an MS-Office 2007 on WinXP
- open a *.doc file with this office from a samba-share
- using an OOo 3.1.1 on SuseLinux 10.1
- Trying to open the same .doc file with this OOo 3.1.1

results in a locking-warning, stating that the file has already been locked and
can only be opened in readonly mode or as a copy.

Same problem for me ..

Server: Windows 2003 R2 Fileserver
Client Windows: Windows XP, MSOffice 2000
Client Linux: Ubuntu 8.04/9.10, OpenOffice.org 3.1.1
Linux Client connected to Win2k3 Server via cifs, also with nobrl option

Opening a .doc with MSOffice 2000 creates a lock-file, which is also visible on
Linux-Side, concurrently opening the same .doc file with OpenOffice.org on
Linux-Side gives no comment or hint, that this document is already opened by
another user ..  Then both lock-files are visible on both clients .. 

Both documents are now writable, last writer wins ..

No Problem when opening the same document with MSOffice and OpenOffice on the
XP Client on the same share .. "The document is access by another user" ..

reopen.

I also tried a slightly different scentario and the problem is reproducable for me.

fileserver: samba 3.0.25b on AIX 5.3
client A: MS Win XP, SP3 - MS Word 2002 SP 3
client B: RHEL 4, connected to fileserver using smbmount -o nobrl
          OOo 3.1.1 (m19)

Steps:
1. Open word document from Client A
2. Open same Document from Client B
-> Document is opened on both clients

In this sceanrio only Client A (Word) is able to write the file. Client B will
get an I/O error when trying to save (once this happended I am not able to 
save the file from Linux side anymore - unless i remount the smb share)

different scenario:
1. Open word document from Client B
2. Open same Document from Client A
-> Document is opened on both clients

Behaviour on save is the same as before.


to compare this with an older version of Ooo I used OOO310m16 on linux side.
1. Open word document from Client A
2. Open same Document from Client B
-> Client B (Linux) correctly reprots that the file is locked

1. Open word document from Client B
2. Open same Document from Client A
-> Client A (Windows) reports the file as invalid (what is not correct, but from
a users POV more save, as it prevents parallel editing and data loss)


Note: in some cases I got a correct lock on the windows side, after a document
was opened from Linux with OOo 3.1.1 - but this rather was the exeptiond and
seemed to happen only after I saved the document from Linux side.

Note: I got the same results when the option "nobrl" was not used on Linux side.


After all we now have three independent sources that confirm the problem. So I'd
assume that there is really something broken. And to me it looks rather like a
general problem with OOo on Linux, not like "happens under rare circumstances only"

If we can do something to track down the root cause, please tell.

mav->andreschnabel:
Sorry, the comments look not to be completely consistent. Which from the
following comments is correct?

"sorry, did not state this yet - the same scenario worked in 3.1.0
(not perfectly, as I got an "I/O" error on my system, but at least the files
were locked)"

"to compare this with an older version of Ooo I used OOO310m16 on linux side.
1. Open word document from Client A
2. Open same Document from Client B
-> Client B (Linux) correctly reprots that the file is locked"


Anyway, as tm has already mentioned, the file locking looks pretty well on our
side in OOo3.1.1, even with the mentioned scenario. So I can believe that there
are problems with the Samba in the mentioned configuration, but it works well if
Samba supports system file locking correctly. So it is indeed a problem that
happens only in case of special environment. Of course it does not make the life
of the unlucky environment owner easier, but it is no general locking problem,
sorry.

By the way, which installation of the office is used. Is it a standard build
from openoffice.org?

Could you please also try the same scenario with OOo2.4 ( instead of OOo3.1.1 )
as I have requested earlier.

andreschnabel->mav:

the I/O error occures, when I first open the doc file from the Linux-Side.

All istallations are standard builds from our website (this is for all reporters)

I was not able to test with 2.4 so far - I need to setup 2.4 on linux first.
(Will do so , if necessary - see below)


andreschnabel->all:
can you all please specify, what version of mount.cifs you use? 

I today, that the scenario works correctly for the environment that I used on
Sept. 25th to confirm the problem. (In other words: files are correctly locked
on the sme system that failed two weeks ago).

There was an update of the smbfs packages on Oct. 1st. Maybe a bug in cifs mount
is the real cause of all of our troubles.

The version that works for me is:
#> smbmount --version
mount.cifs version: 1.12-3.3.2

Just to make sure, that there are no missunderstandings...

Some of you talk about a Samba share. This sounds like you tested using a SMB
share hosted on a Unix/Linux/AIX server. This is not my infrastructure: I'm
using a native Windows server. This might be of relevance as there are different
(not 100% compatible) locking strategies on Unix/Linux (clients) and Windows
(server and client).

Please ensure, that you are testing with cifs mount option nobrl enabled!

I tested again using Windows XP pro as file server (I have no server 2003
available). File locking is OK.

@tserries: 
can you please check with a new sambafs (mount.cifs) package on your Linux
client? Packages built after 2009-10-01 work for me, while older packages do not.

@andreschnabel: Could you please provide the source code of the sambafs
(mount.cifs) version working for you; or tell me how to get this version. We
could not find this version.

@andreschnabel: Just tested with Ubuntu 9.10 (Karmic) and OpenOffice.org 3.1.1
(build 9420). The problem is unchanged: If a MSO file is opened by MSO on
Windows and OpenOffice on Linux (using cifs with noblr option set) in parallel,
there is no locking at all. Both systems get write access an are able to modify
the file. The last write wins.

My test infrastructure (Linux):
$ dpkg -l|grep samba
ii  samba-common       2:3.4.0-3ubuntu5.1    [...]
ii  samba-common-bin   2:3.4.0-3ubuntu5.1    [...]

$ smbmount --version
mount.cifs version: 1.12-3.4.0

If further information is needed, please let me know.

TM->MAV: please have a look, again.

tried again after update to kubuntu 9.10 - samba packages have now exactly the
same versions as at t_serries' environment:

$ dpkg -l|grep samba
ii  samba-common       2:3.4.0-3ubuntu5.1    [...]
ii  samba-common-bin   2:3.4.0-3ubuntu5.1    [...]

$ smbmount --version
mount.cifs version: 1.12-3.4.0


I still have no problem. When mounting with -o nobrl , all works as expected
(second app to open the file will open in read-only mode) 

Mounting without noblr will give an file access error, but at least the file is
locked.

(tried with samba and WinXP as file server)

Ok, based on the testing and investigations, that were done by andreschnabel and
tm, it looks like the bug is in samba configuration ( and probably was in some
samba versions implementations ), and thus can not be really solved in OOo.

Adjusting the Summary accordingly. Closing the bug as working for me, please
reopen it in case there is a way to show that the problem lies in OOo
implementation.

.