Issue 54567 - Input/output error on network-shared documents
Summary: Input/output error on network-shared documents
Status: CLOSED DUPLICATE of issue 85794
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 680m125
Hardware: All All
: P3 Trivial with 17 votes (vote)
Target Milestone: OOo 2.x
Assignee: hennes.rohling
QA Contact: issues@framework
: 52531 56926 57421 58215 65464 68348 (view as issue list)
Depends on:
Reported: 2005-09-13 20:10 UTC by lomograf
Modified: 2008-11-05 20:37 UTC (History)
17 users (show)

See Also:
Issue Type: TASK
Latest Confirmation in: ---
Developer Difficulty: ---

log file from Samba server (12.24 KB, application/x-gzip)
2006-12-12 14:46 UTC, tuharsky
no flags Details
log from Samba server while trying to create ls.log (3.73 KB, application/x-gzip)
2006-12-12 14:49 UTC, tuharsky
no flags Details
ls log from the actual directory (6.94 KB, text/plain)
2006-12-12 14:51 UTC, tuharsky
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lomograf 2005-09-13 20:10:44 UTC

I get an I/O Error while I try to store a file on a SMB-mounted Device
(SMB-mounted shared Mac (OSX 10.3.8) reacts equal to my antique SUSE 7.2 server). 
If I store the file locally and afterwards copy it to the SMB-Device: no problems.
No storage problems with other programs (i.e. Photoshop, SubEthaEdit etc.)

My system: OSX 10.3.8, G4-400ti, in a multi-OS network.

Is there anybody who can confirm this?
Is this a Bug conccerning OOo 2.0 or Mac X11?
Is there a Workaround/Patch?

(this is my first issue - please be patient: is this the right
Comment 1 Olaf Felka 2005-09-14 08:25:49 UTC
Comment 2 dcnarad 2005-10-16 03:58:39 UTC

I have been experiencing the same problem. Not only can I not save on a SMB
network drive I cant even open files from that drive. The program gives an I/O
error but saves a 0kb .odt file. It is not a problem with one or the other
component write, calc and impress all do the same. I am pretty sure it is not a
problem with the OS (Mac OSX 10.4) since my neooffice/j and M$ office opens them
fine and saves them too. I took a couple of screen shots but don't kno how to
up-load it into this page (i dont see an option for attachments)
it reads (de-accented)
Opening error: Erreur generale d'entree/sortie lors de l'acces a
Saving error: erreur lors de l'enregistrement du document sans nom1: Erreur
generale sortilors de l'access a /volumes/devbio/***/***/***/***.odt


Comment 3 jogi 2005-11-01 09:33:10 UTC
*** Issue 56926 has been marked as a duplicate of this issue. ***
Comment 4 jogi 2005-11-01 09:39:59 UTC
work around:

exclude with a # (hash)
in soffice start script (View package content -> Contents .... /program/soffice).
Comment 5 lomograf 2005-11-03 08:25:02 UTC

thanx - the workaround works for me.

To change the file, you have to have administrator rights
You should then use the Terminal - pico editor.

Comment 6 atdsm 2005-11-22 13:53:36 UTC
*** Issue 57421 has been marked as a duplicate of this issue. ***
Comment 7 tuharsky 2005-11-29 07:43:52 UTC
The workaround dosen't fully work for us.

After applying the change, the frequency of bug appearance has lowered. When
error occurs, user is now able to save the document. For example, autosave
generated eroor, but then I used manual save and this worked. Saving with
different name worked partially, OOo has frozen after save and the file was
considered damaged when opening next time.

So, the workaround works, but DOES NOT RESOLVE THE WHOLE PROBLEM.
Comment 8 tuharsky 2005-11-30 07:25:40 UTC
As of NFS, the workaround works to extent, that NFS files can be opened now (it
has been impossible before).

I cannot say if it removes the whole problem from NFS -I haven't tested it much
so I don't know, if there'll be not casual error on saving the document, such as
in the case of SMB.
Comment 9 thorsten.martens 2005-11-30 08:40:25 UTC
*** Issue 58215 has been marked as a duplicate of this issue. ***
Comment 10 lorenzoneri 2005-12-01 18:37:50 UTC
Hello , we've the same problem since the first version of OOo . We store the
document on a server with a samba partition . When we try to open one of this
document directly from the server , OOO fall in error . We must make a copy of
it on our desktop , work on it , save and after replace it on the samba
partition . This happens with OP on the clients windowsXP or linux independently
. We've never resolve the problem unfortunately but sincerly I've not understood
how to apply the "work around" written below . It works only for Mac ? 

Thanks to all , Lorenzo
Comment 11 tuharsky 2005-12-02 13:34:47 UTC
Please, someone with sufficient privilegues, do perform these changes:

Platform: All
OS: All
Summary: Input/Output error on network-shared documents
Status: NEW
Comment 12 xplab 2005-12-04 11:28:46 UTC
The work around outlined by jsi perhaps is applicable if the client is Oo for Mac.
Our situation is : Windows client and Mac 0sx 10.4.3 server.
So we have to applie the WA to a windows Oo and we have not found the way.
Some one can help to find the applicable INI option?

Comment 13 lorenzoneri 2005-12-20 15:36:03 UTC
Any news about this unsolved problem ? 
Many thanks ... Lorenzo 
Comment 14 errorist 2006-01-15 00:35:16 UTC
I'm having the same problem with OOo 2.0.1-1-i568 (Debian) and various NFS-shares.
OOo 1.x (from 1.1-1.5) worked fine. So does smb-Access with OOo 2.0.1 (Windows
and Debian).
The workaround (SAL_ENABLE_FILE_LOCKING=1) has already been commented out by
installation. Setting SAL_ENABLE_FILE_LOCKING=0 and exporting it didn't help either.
Let me know, when I can help in testing.

Comment 15 martinkozak 2006-02-04 10:33:52 UTC
Significantly reported on Windows.
Comment 16 martinkozak 2006-02-04 10:38:10 UTC
Can anyone confirm it happens while Linux to Samba accessing, please?
Comment 17 martinkozak 2006-02-04 10:51:25 UTC

We've significantly recorded this problem on Mac OS X and on almost all Windows 
versions, but it isn't clear, when this problem occurs - its behaviour isn't 
regular on all configurations although the base enviroments are the same - Samba 
and Windows or Mac OS X as server or client. 

We have reports, it occurs, and reports, there is no problem. It is very 
questionable - probably, i think, because of some 
configuration incompatibilities.


Martin Kozák
(CS User Support Leader)

Comment 18 tiger_stechovice 2006-02-05 20:29:06 UTC
*** Issue 54567 has been confirmed by votes. ***
Comment 19 tuharsky 2006-02-06 13:59:10 UTC
Could it be marked P2?

When facing this problem, we have had situation here, that in consequence, the
document has been overwritten by zero-sized one (despite of claiming the "I/O
error). Once the OOo has been closed (and it probably HAS BEEN because it often
crashed after the error), the document has been COMPLETELY GONE!
Comment 20 martinkozak 2006-02-06 18:03:22 UTC
We need more info. Should be well to make clear, when problem occurs. This is 
relatively important problem, but nobody doesn't know anything about it.
Martin Kozák
CS User Support Leader
Comment 21 martinkozak 2006-02-06 18:51:04 UTC
*** Issue 52531 has been marked as a duplicate of this issue. ***
Comment 22 tuharsky 2006-02-27 10:27:51 UTC
Please, could anybody tell us, the users, what could we do to help solving this

And could it FINALLY be marked P2?

I still got Linux, rarely even Windows users that couldn't save their documents
becouse of this ****ing problem.

Taking in account, how this bug is annoying and how it leads to data loss, I
wonder how could NOTHING happen for nearly HALF YEAR since it has been reported.

Files randomly don't save, OOo20 crashes with "General I/O error" and nobody
really cares.
Comment 23 tuharsky 2006-02-27 10:35:44 UTC
martinkozak: Yes, it affects Linux/Samba too. It affects all systems (excepting
Solaris that I don't know). There is significant number of duplicates of this
issue and they include a rich bunch of systems:

Issue 56926
Issue 57421
Issue 58215
Issue 52531
Comment 24 tuharsky 2006-04-10 06:56:15 UTC
I will try to sumarise what users from cs-mailing list said regarding this problem.
Comment 25 tuharsky 2006-04-10 06:56:45 UTC
28.03.2006 08:13 user Shipowner said:
Saving files using VPS Hamachi, TC, OfficeXP performs all well, only claims "General Input/Output error". I then put the document on
local drive and copy it to server using file manager.

Other "pearl": I open OOo Calc, use Open File and browse to server, where I open
document from then. Calc opens, however data is not there. I must "touch" the
server using commander, copy the spreadsheet to local PC and open from it. It
opens again, however now it contains needed data..
Comment 26 tuharsky 2006-04-10 06:57:00 UTC
27.03.2006 09:19 user Petr Štefánik wrote:
I feel that if the server share is mapped as drive in Windows clients, no
problem appears.
Comment 27 tuharsky 2006-04-10 06:57:12 UTC
27.03.2006 09:23 user Evžen Hlavica wrote:
I use OOo 2.0.1 under W_XP/2000/98SE and whole data is stored on W_NT/4.0 SP4
server. Shared directories are mapped as drives in Windows (using login script).
I haven's got any problems.
Comment 28 tuharsky 2006-04-10 06:57:23 UTC
27.03.2006 12:56 Daniel Hrbac wrote:
I run OOo under WXP, data are stored on SAMBA. I get this error in the case when
mapped drives disconnect for some reason. It's enough then to run explorer,
mouse click on the mapped drives, they reconnect/actualise and OOo saves the
data. It looks like OOo cannot touch the files the way to actualise the
connection for himself.
Comment 29 tuharsky 2006-04-10 06:57:35 UTC
See also Issue 63672
Comment 30 tuharsky 2006-04-10 06:57:50 UTC
27.03.2006 17:50 Lumir Pribyl wrote:
Problems with reconnecting mapped drives in WXP client versus SAMBA/Linux server
-they have been completely resolved by upgrade WXP SP to WXP SP2.

It is rumored that WXP SP1, while mapping the drive, waits for some output from
some obscure, totally independent function, and he of course dosen't get that
from Linux server. In SP2 it probably got fixed.
Comment 31 tuharsky 2006-04-10 06:58:01 UTC
27.03.2006 21:03 Daniel Hrbac wrote:
For me, the WXP SP2 DIDN't solve the problem. Look at Issue 63672.
Comment 32 tuharsky 2006-04-10 06:58:14 UTC
28.03.2006 00:41 Uhrak.ServIT wrote:
Gentleman, this bug (hopefully not a feature) is appearing not for the first
time. It seems that it is specific for server/client configuration, might also
depend on other software installed ( onserver?client?)

In work we use RH9/SAMBA, W2k3 with shared drives, some users also share their
I've got Mandriva2006 as server with samba3 + NFS + FTP +.. (You know that
stuff), clients the same + WXP also. I haven't ever noticed problems (since the
OOo 1.0.1) regarding saving the documents. Dosen't matter if they were or
weren't mapped (Win versus \\server\path..). Dosen't matter if it even has been
NFS share.
However, I have activated NFS recently and there have been problems with OPENING
the file (Mandriva 2006). I've been able to save only. I played a little with
settings of NFSD, and the upgrade to NFS3 really helped. It might have been set
to protocol version 2 by default. I don't really understand the stuff generally.

It's pitty that we can't find the exact suspect. More PC's with the same
problem, server configuration, which are problematic and which aren't..
Comment 33 tuharsky 2006-04-10 06:58:31 UTC
I can say, that in case of NFS, I have been unable to open files from NFS share
too. (Issue 58215).

Workaround from Issue 54567
jsi Tue Nov 1 02:39:59 -0700 2005 -------

exclude with a # (hash)
in soffice start script (View package content -> Contents .... /program/soffice).

I tested it and it completely helped with NFS, however it dosen't help much with
Linux client + Linux server }SAMBA|.
Comment 34 tuharsky 2006-04-10 06:58:43 UTC
28.03.2006 01:02 Daniel Hrbac wrote:

Well, one test case

client1: WinXP SP2, OOo 2.0
client2: dtto
documents on shared drive X:\Akta on \\Akserver\Akta

server: Mandriva linux 2006.0 actualised from stable
fs: ext3

# Samba config file created using SWAT
# from UNKNOWN (
# Date: 2004/03/23 15:36:02

# Global parameters
    log file = /var/log/samba/log.%m
    client code page = 0
    character set = ISO8859-2
    socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
    hosts equiv = /etc/hosts.allow
    guest ok = Yes
    create mask = 0777
    interfaces =
    map to guest = Bad User
    null passwords = yes
    encrypt passwords = yes
    hosts allow = localhost
    printer admin = @adm
    dns proxy = No
    netbios name = AKSERVER
    mangle case = Yes
    printing = cups
    writable = yes
    workgroup = FJD
    directory mask = 0777
    comment = Akta
    printcap name = cups
    security = SHARE
    preload = global
    max log size = 50

    force create mode = 0660
    oplocks = no
    force user = samba
    path = /data/Akta
    force directory mode = 0770
    force group = users 

Comment 35 tuharsky 2006-04-10 06:58:55 UTC
Daniel Hrbac also wrote:

Try issue 63672 with this config and tell, if writing works. I can reproduce the
error anytime.
Comment 36 tuharsky 2006-04-10 06:59:11 UTC
04.04.2006 18:35 Uhrak.ServIT wrote:

because my configuration is similar to Daniel's, I'm posting my smb.conf. It
would be fine if it has been enough to just change some setting from his one.
However I cannot figure, what problem they have on Windows servers..

This SAMBA configuration works flawlessly both with WXP and Mandrivou2006.
Server is also Mandriva 2006.

# Samba config file created using SWAT
# from (
# Date: 2006/03/28 20:25:06

# Global parameters
    dos charset = 852
    unix charset = ISO8859-2
    workgroup = DOMA
    server string = Samba
    interfaces =
    auth methods = guest, sam, winbind
    update encrypted = Yes
    allow trusted domains = No
    min password length = 0
    map to guest = Bad User
    null passwords = Yes
    obey pam restrictions = Yes
    password server =     pam password change = Yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *New*password* %n\n *Retype*new*password* %n\n
    username level = 5
    unix password sync = Yes
    log file = /var/log/samba/%m.log
    max log size = 0
    debug pid = Yes
    debug uid = Yes
    time server = Yes
    paranoid server security = No
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    logon path =     logon home =     os level = 33
    preferred master = Yes
    dns proxy = No
    wins support = Yes
    ldap ssl = no
    preload = %U
    guest ok = Yes

    comment = Muj adresar
    path = /opt/ftp/%u/
    username = %S
    read only = No
    create mask = 0664
    directory mask = 0775
    guest ok = No
    browseable = No

    comment = film
    path = /opt2/filmy

    comment = hudba
    path = /opt2/hudba

    comment = income
    path = /opt/ftp/pub/income
    read only = No

    path = /opt/ftp/pub/sw
    write list = milan
    browseable = No

    path = /opt/samba/Dokumenty
    write list = milan

    path = /var/spool/samba
    printer admin = milan
    max print jobs = 10
    printable = Yes
    cups options = lpr-cups -P %p -o raw %s -r
    printer name = tp0
    use client driver = Yes

    path = /opt/ftp/pub/Drivers
    admin users = milan
    write list = milan 
Comment 37 tuharsky 2006-04-10 06:59:51 UTC
That's it. Someone has been looking for more information, so I have provided as
much information as I have.
Comment 38 michael.ruess 2006-04-18 08:34:19 UTC
Removed mru from cc.
Comment 39 jsiegmann 2006-05-08 14:08:41 UTC
We are working on a small network of 4 Computer (Workstation Setting) under Win
XP all Computer SP2 and having on all Computers the same problem since updating
from OO 2.0 to OO 2.0.1. and OO 2.0.2.
As we are working daily with the same docs from our main workstation this
situation is more than annoying. We have had the same problem after updating
from 1.1.3 to 1.1.4. This problem has been solved when updating to 2.0 beta. I
guess it is the same problem we had with the 1.1.4 version.

Comment 40 Olaf Felka 2006-05-17 08:45:52 UTC
*** Issue 65464 has been marked as a duplicate of this issue. ***
Comment 41 mcamou 2006-05-17 15:22:15 UTC
Confirmed the SAL_ENABLE_FILE_LOCKING=1 on OS X 10.4.6 on PPC and Intel with
both Samba and AFP servers
Comment 42 mcamou 2006-05-17 15:22:45 UTC
Confirmed the SAL_ENABLE_FILE_LOCKING=1 on OS X 10.4.6 on PPC and Intel with
both Samba and AFP servers
Comment 43 cervajs 2006-06-14 14:05:28 UTC
client: linux/FC5 OOo 2.0.2
server: linux/FC4 samba 3.0.14a

edit existing document 
- first save -> "could not create backup copy"
- second save - ok
Comment 44 sprauems 2006-08-29 23:08:08 UTC
This is why Open Source will never be taken seriously, bunch of hacks thinking 
they're programmers though they think the real issues are worth dealing with.

Seem pretty much layed out there.  Somewhere the path is not able to see 
network when being saved.  Works good to the local drives - seems like a 
logical place to start looking from.

Fill free to kick me off this site - isn't worth a sh^t anyhow!

Comment 45 Martin Hollmichel 2006-09-28 12:49:25 UTC
wrong owner, reassign.
Comment 46 philipp.lohmann 2006-10-04 10:09:14 UTC
That's not my turf. hro: could you please have a look ?
Comment 47 Mathias_Bauer 2006-11-03 08:12:39 UTC
Comment 48 tuharsky 2006-12-12 14:45:28 UTC
Suddenly, the error occured for me.

Fortunately, I've got debug mode turned on on the Samba server. So I'm posting
logs. I have had file rozpocet 2006.sxc opened and tryed to save it as reozpocet

Samba version is 3.0.14a-3sarge2 (Debian Sarge) on server and 3.0.23d-1 on
client (Debian Etch).
Comment 49 tuharsky 2006-12-12 14:46:35 UTC
Created attachment 41372 [details]
log file from Samba server
Comment 50 tuharsky 2006-12-12 14:48:36 UTC
What's strange, after the error, I cannot even create a file from console on
that path. I tryed to do ls >ls.log and here's the log from samba server. I got
kinda "no such file or directory" error.
Comment 51 tuharsky 2006-12-12 14:49:35 UTC
Created attachment 41373 [details]
log from Samba server while trying to create ls.log
Comment 52 tuharsky 2006-12-12 14:51:09 UTC
It is quite interesting, that Samba seems to process every file in the directory
by some means.

Could possibly the bug be caused by usage of diacritical symbols in the file names?

I'm posting ls -la log
Comment 53 tuharsky 2006-12-12 14:51:58 UTC
Created attachment 41374 [details]
ls log from the actual directory
Comment 54 tuharsky 2006-12-12 14:54:50 UTC
Oops, I was so excited by the possibility of logging that I overlooked, that I
didn't have an access to the directory in fact.

Consider my todays previous posts as false.
Comment 55 tuharsky 2006-12-12 14:55:57 UTC
Please, could someone remove the misleading attachments, please? I'm not allowed

I'm sorry. Was too happy to help with the pesky bug..
Comment 56 Mathias_Bauer 2006-12-13 14:43:17 UTC
No problem, thanks for trying to help us.
Comment 57 tinca 2007-01-26 13:39:31 UTC
On my system I get:

Error saving the document Untitled1:
The operation on
<my-network-path>t.odt was started with an invalid parameter.

No saving happens.
The same error is reported on reading a file.
The problem can be repeated using OO 1.1.5.

In 2.0.4's soffice script the lines:

 are enabled by default. Disabling them allows OO to work, but
 then no locking of the given file happens, that is almost as
unacceptable in a workgroup, as not being able to r/w.

- network drive served by Windows
- client: FreeBSD 6.1 with smbnetfs
Comment 58 Rainer Bielefeld 2007-02-17 11:56:25 UTC
*** Issue 68348 has been marked as a duplicate of this issue. ***
Comment 59 tinca 2007-02-19 07:59:15 UTC
Now, Issue 68348 and this cross-references each other (OK, if it is so intended)

I just wanted to add that the problem still exists for 2.1.
Comment 60 hennes.rohling 2007-02-19 12:30:59 UTC
Though this issue is a mixup of different scenarios most of the problems might
be caused by the fact that network connections may be going down while OOo has
the file open -> file handle is no longer valid.

Need a mechanism to reopen a broken network file handle.

Setting Target to 3.0
Comment 61 tuharsky 2007-02-19 13:15:15 UTC
How do You imagine the "network connections going down"?
Comment 62 tuharsky 2007-02-19 13:32:52 UTC
Although I tend to be polite, I must object the target milestone 3.0.

This bug annoys users for year and half, it is P2-grade bug (data loss). Taking
in account, that the bug was uncovered as soon as during 2.0 BETA stage, should
been fixed even BEFORE 2.0. It's bad enough that it made it to the stable 2.0,
bad enough it was not fixed for 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.1 and just pushed
to 2.x. Pushing it towards next major is really bad. What will be done then?
Pushed to 3.x and then to 4.0?

Cite: "Issues with this priority must be fixed before the target release (see
Target milestone), which usually is the next major release, and should be dealt
with as soon as possible. Not fixing them for the target release is not acceptable."

Cite: "# User data is corrupted in an easy-to-encounter way;
e.g. saving a document corrupts the resulting file and renders it unusable
# Crashs or freezes during normal operations of the application"

Pushing the bugs does not resolve them, nor it makes users happy. I'd rather
spend more time waiting for next release to see the bugs actually fixed, than
watching bazillions of releases with no visible progress on serious bugs. I'm
happy for tiny tweaks here and there, but this dosen't make the major bugs
dissappear. Could anything annoy users even more than severe, well-known,
years-lasting bug?
Comment 63 hennes.rohling 2007-02-19 13:59:04 UTC
I'm working in a heterogene network infrastructure with NFS, Samba, NT Servers
and client on Windows, Solaris and Linux.

The problem is not reproducable here.

I don't want to talk about the technical background, but most of those problems
occur because of misconfigured network evironments (f.e. samba configuration).

Every network file system/client has different underlying locking mechanism
which have to be translated.

OOo uses the common C runtime APIs for locking. What's going on under the hood
is not OOo but it's the operating system/network file system layer.

This issue is a mixup of completly different scenarios, different servers,
different clients, different OS, different problems.

Read the comments of this issue (including yours ;-)) You wrote that there's a
problem on WinXP if the drive mapping has gone for some reason. Others said the
problem has gone with XP SP" the next one says it's still there.
Maybe there's a problem when using UNC network paths instead of mapped drives.
If so this would be a complete different problem than using a Linux served SAMBA

What OOo might handle different than other apps is that it holds the file handle
open. That's a problem when the network connection has gone.

Not enough resources to fix this for next micro release. Setting Prio to P3

Comment 64 tuharsky 2007-02-19 14:05:05 UTC
Whoaa, lowering the priority, I wonder, who would expect this? Well, actually,
anyone who has ever made a deal with OOo P2 dataloss grade bugs.
Comment 65 tuharsky 2007-02-19 14:12:39 UTC
"Not enough resources to fix this for next micro release. Setting Prio to P3"

Not enough resources ..this is pretty clear for most long-time OOo users.
Setting Prio ..this is common mistake here in OOo. How could low resources
implict lower priority of severe bugs?

The bugs are not less serious becouse of lack of resources. This is just
sweeping the crap under the bed.

Just face the problem.
-Yes, there are dozen of P2 bugs in OOo.
-Yes, we don't have resources to fix them.
-Yes, there will not be major release anytime soon, because it dosen't make
sense to shoot out major releases with years lasting P2 bugs.
Comment 66 tuharsky 2007-02-19 14:24:55 UTC
>Every network file system/client has different underlying locking mechanism
which have to be translated.

Yes. Many have kernel-level support mechanisms to handle that, luckily.

>OOo uses the common C runtime APIs for locking. What's going on under the hood
is not OOo but it's the operating system/network file system layer.

Please, try to connect this with the simple fact, that there is NOT any other
program known, that produces this error. It's ONLY the OOo, and ONLY after 680m125!

>Read the comments of this issue (including yours ;-)) You wrote that there's a
problem on WinXP if the drive mapping has gone for some reason. Others said the
problem has gone with XP SP" the next one says it's still there.
Maybe there's a problem when using UNC network paths instead of mapped drives.
If so this would be a complete different problem than using a Linux served SAMBA

My comments are from bigger part just comments made by users in ooo-cs mailing
list. I took them and translated here to help with recognizing the problem.

Yes, the issue seems to have several paths of impact. However, not easy to
"decode" and with no uniform results.
One could have something to do with mapped/not mapped network shares.
Another one means that opening a document from Linux-Linux Samba connection
makes OOo loss Your data with quite a probability.

>What OOo might handle different than other apps is that it holds the file
handle open. That's a problem when the network connection has gone.

Now if this is that easy, then it should be reasonably easy to solve the whole
problem. Just do it the same way the M$Office does?
Comment 67 hennes.rohling 2007-02-20 11:49:15 UTC
My mistake, I meant target 2.3 :-)
Comment 68 hennes.rohling 2007-03-05 09:34:53 UTC
Comment 69 mux2005 2007-03-06 09:57:06 UTC
@hro: I'm happy to see that work on this issue has been started. 
What kind of locking issues will the fix resolve. E.g. we've observed that in
some situations opening a file on a Samba share with OOo from a Windows machine
and then attempting to open the same file with OOo from a Linux machine gave an
I/O error on the Linux machine rather than an end-user suitable message that the
file is locked by another user. Is it forseeable that the fix for this issue
will resolve this problem, too, or is that another issue?
Comment 70 Mathias_Bauer 2007-05-03 12:20:47 UTC
*** Issue 76865 has been marked as a duplicate of this issue. ***
Comment 71 hennes.rohling 2007-05-22 18:23:46 UTC
@mux2005: What you stated is that cross platform file locking works but the
message that pops up isn't clear enough. You might flag this as a defect but of
less severity.

Other here seem to have the problem that file locking does not work at all.
Comment 72 hennes.rohling 2007-06-29 15:47:13 UTC
Because the mixup of different scenarios that can't be fixed we will first of
all provide a HOWTO setup a samba server to a working environement within 2.3
time frame.
Comment 73 nmailhot 2007-06-29 16:01:04 UTC
This will be useless for a lot of people.

My own scenario is simple: windows client, windows serveur, laptop with wired
ethernet (our IT people haven't decided yet to do wifi)

LAN cable is often disconnected (moving laptop somewhere else, flacky ethernet
connectors in the building). When it's reconnected every app just restarts using
the network share except for Oo.o that 
1. first displays an unhelpful popup about the original location not being
accessible (it is, the cable has been replugged)
2. then quickly proceeds to lose data if you try to save your file somewhere else.

How a samba doc setup is going to help me?

You may write I've got a different issue, except other OO.o people duped it
there, so they clearly consider it the same problem.
Comment 74 hennes.rohling 2007-06-29 16:42:58 UTC
Again and again: Please refrain from mixing complete different issues !!! 

If this mixup goes on I'll close this and every furture task of this kind "me
too, I got problems with files on the network, must be the same".

@nmailhot: See issue i73979, this would be yours, has nothing to do with file
locking/file accessing problem in heterogene networks that are connected the
whole time.
Comment 75 hennes.rohling 2007-07-19 11:43:55 UTC
Target set
Comment 76 pluby 2007-08-14 18:24:58 UTC
FYI. I may have stumbled across the cause of this bug and, in our case, the
cause was found to be that either of the following products on a Mac OS X
machine had the file open: X11 or NeoOffice.

Although I initially suspected that the bug was in SAMBA or the OOo Windows
code, I eventually found that the code that caused this problem was the Mac OS X
code in sal/osl/unx/file.cxx.

Some time ago, a Sun engineer changed the file locking code from using the Linux
and Solaris file locking logic to custom logic. In short, by reverting the file
locking code back to using the Linux and Solaris logic, opening a file from Mac
OS X no longer caused errors for OOo Windows clients.

To determine if this bug is the same as the bug I found, try the following:

1. Determine if you have any Mac OS X machines that are connected to your SAMBA
file server that are running OOo X11 or NeoOffice. If the answer is no, then
ignore this post as it isn't applicable to your case.

2. Open a file that no machine has open on a Mac OS X machine using a recent
version of OOo X11 or NeoOffice.

3. After the file is opened in writable mode on Mac OS X, try opening the file
using OOo Windows.

If you cannot open the file and OOo Windows gives you an error dialog, then this
is likely to be the cause of the bug. If you want to be absolutely sure that
this is the cause, install NeoOffice 2.1 plus Test Patch 9 from the following
URL (search for Patch-7-Test-9 in the bug to find the test patch URL for your
Mac OS X platform):

Once you have NeoOffice 2.1 plus Test Patch 9 installed, repeat steps 1 through
3. If OOo Windows can now open the file in read-only mode, then we have
confirmed the cause of the bug.

For the Sun developers, the fix is very simple: remove all of the following
custom Mac OS X code from sal/osl/unx/file.cxx so that file locking is handled
the same as Linux and Solaris:

Comment 77 tinca 2007-10-01 08:59:11 UTC
The version 2.3 (target for this bug as seen in the comments, not seen in 
issue's header) is out, but no mention of the issue is in the release notes. 
Can we learn about when it is to be solved?
Comment 78 exexcel 2007-12-04 21:18:07 UTC
for me it makes a difference if i mount the samba-share as filesystem smbfs or
cifs. with smbfs it works, with cifs it's like:

edit existing document 
- first save -> "could not create backup copy"
- second save - ok

(sadly cifs is much faster than smbfs)

client: ubuntu 7.10, OOo 2.3
server: samba 3.0.x

with another windows-PC with the same OOo version there's also no problem.
Comment 79 kpalagin 2008-01-30 10:10:34 UTC
please consider this defect for 3.0.
Comment 80 hennes.rohling 2008-02-04 11:35:41 UTC
As I've already mentioned file system locking causes problems with heterogene
network file systems.
This is not really fixable for all scenarios. OOo relies on file locking
mechanisms so we try to archive a non file system based locking for OOo 3.0.

Setting as duplicate to follow-up issue.

*** This issue has been marked as a duplicate of 85794 ***
Comment 81 Mechtilde 2008-11-05 20:37:27 UTC
close the duplicate