First Test environment : Macmini 10.6 SL Server with AFS Share Mac client : Macbook Pro SL 10.6 with LibO 3.4.3 Mac client : Macmini Tiger 10.4 with LibO 3.3.1 Second Test Environment : Mac clients/server : 10.5 Leopard with AFS share activated. How to reproduce : A first client machine opens a file located on the AFS share, e.g. doc, docx, ds, odt, odp, etc. A second client machine then attempts to open the same. Expected result : Error message that file is being used, file can only be opened in RO mode. Actual result : an error message is displayed with read/write I/O error and the file is not opened on the second client machine. This is a regression with regard to OOo 3.3.0 where AFS concurrent locking works. Alex
Bug confirmed with : Xserver 10.5 which share folders over AFP. Mac clients 10.5 or 10.6 with LibO 3.3.0 to 3.4.3 Generally, LibO can't open at all an already opened file on AFP shared folder (error message instead of open in read only) For exemple, open a .doc file with MS Word. Then try to open the same file with LibO. We try with the sames shared folders over SMB (Samba) and no problems occured.
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
This bug always occur with 3.5b3 I've discover that the problem seems to be a lock of the file itself (xxx.ods). (The ".~lock.xxx.ods#" file seems to make his job) For example, deleting the .~lock.xxx.ods# file doesn't make the file openable. I've also discover that the sharing mode work perfectly. Many users can open the same file at time. (and edit it)
3.4 lifecycle is terminated, I delete useless relation to 3.4 MAB, Blocking “Bug 37361 LibreOffice 3.5 most annoying bugs” remains.
<http://wiki.documentfoundation.org/BugReport_Details#Version>
I would like to insist on this bug which is very inconvenient for all Mac users in business. It did not occur with OpenOffice.org, it is only with LibreOffice it appeared. The same bug affect Apache OpenOffice 3.4. How to reproduce: You need to have 3 macs : 1 server 2 clients I've only try with MacOS leopard 10.5 server. On the server configure AFP shared folder. On the two client connect to this folder. ( afp://myserver.com ) Open an odt file (but same bug with all files) on the first client Open the same file on the over client. You will see this message : "Error during shared access to /Volumes/MySharedFolder/myfile.odt." And the file can't be opened at all, even in read only.
Only 1 MAB tracker! Seems I reverted to wrong version I doubt that this one is not Critical for the project. @MacExperts: Any idea how we can get some progress here?
> @MacExperts: > Any idea how we can get some progress here? I can see whether I'm able to set up a test scenario locally here, but only in ~2 weeks time. (What comes to mind is AFS-specific code related to file locking in sal/osl/unx/file.cxx osl_file_adjustLockFlags.)
Thank you to interest you show in the resolution of this bug. I was able to reproduce with a different configuration: A server in Leo 10.7.3 10.7.4 a customer lion 1 customer Snow Leopard 10.6.x
1 server Lion 10.7.3 1 client Lion 10.7.4 1 client snow leopard 10.6.x
This bug may be related to those ones : https://issues.apache.org/ooo/show_bug.cgi?id=29284 https://issues.apache.org/ooo/show_bug.cgi?id=62229 I've try to comment SAL_ENABLE_FILE_LOCKING=1 export SAL_ENABLE_FILE_LOCKING in LibreOffice.app/Contents/MacOS/gengal file But it don't change anything.
*** Bug 45902 has been marked as a duplicate of this bug. ***
For information, we have paid someone to work on this issue. We hope it will be resolved soon.
(In reply to comment #13) > For information, > we have paid someone to work on this issue. We hope it will be resolved soon. Thank you very much!
3.5 is at the end of its life cycle so we are closing the 3.5 MAB meta tracker. I will port this over to 3.6 MAB. Personally I don't think it qualifies but since a developer has been paid to fix the issue, hopefully we see it fixed soon. @Reporter and others - thanks for the input and clear steps to reproduce!
fabien - out of interest, who did you pay - and how did it work out ? :-) Thanks !
(In reply to comment #13) > For information, > we have paid someone to work on this issue. We hope it will be resolved soon. Fabien, Did you get this issue resolved ? Alex
(In reply to comment #17) > (In reply to comment #13) > > For information, > > we have paid someone to work on this issue. We hope it will be resolved soon. > > Fabien, > > Did you get this issue resolved ? > > Alex +1. did that paid developer fix the bug?
is this still an issue with recent 4.0.4 and 4.1.0 releases?
in libreoffice 4.0.4.2 it is still the same, I can not edit and save a .bau-file on a afp share => afp error -5010
Why did you mark it as assigned, who is it assigned to?
Joel Madero > Why did you mark it as assigned, who is it assigned to? oh, sorry - I was not sure what is the best: new? - no resolved? - no need info? - ? assigned? - I take this set it to the right status, please :)
Assigned it to you ;)
(In reply to comment #23) > Assigned it to you ;) But, Benjamin, are you currently working on a fix? Otherwise, it does not make sense to have it assigned to you (and it should rather be NEW then).
Stephan Bergmann > But, Benjamin, are you currently working on a fix? no, I have only tested 4.0.4.2 for this issue. > Otherwise, it does not make sense to have it assigned to you (and it should rather be NEW then). okay, I have set this, sorry for chaos
moving from mab3.6 list to mab4.0 list since 3.6.x is EOL
We have no news of the guy we should have to pay to work on it. I think he completely abandon the subject. Sorry for the false hope.
(This is an automated message.) Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Could someone test if this is still an issue in 4.1 and/or 4.2?
> Could someone test if this is still an issue in 4.1 and/or 4.2? tested and still unimproved in 4.1.5 and 4.2.0 :/(In reply to comment #29)
moving from mab4.0 to mab4.1 since LibO 4.0.x reached end of life
is this bug still valid in current 4.2.4.2 release? if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL
Bug still not fixed. Added to mab4.2
please retest with 4.3.x and 4.4.x if bug is still there please move it to mab4.3 list
Version: 4.5.0.0.alpha0+ Build ID: 1658c017a27ac2cccb2af89f88a4cde8ffdbe531 Locale: fr_ wfm, the warning message now gives user choice to either open read only, or open (override file locking).
Tested on osx 10.10.1
*** Bug 89052 has been marked as a duplicate of this bug. ***