Apache OpenOffice (AOO) Bugzilla – Issue 62229
Cannot acccess any resources via AFP
Last modified: 2007-02-05 13:33:25 UTC
Any attempt to access any resource via AFP fails. This is especially problematic apparently when a user's home directory is remotely mounted, which is now a fairly typical configuration being promoted by Apple. If you do attempt to save a file remotely you will get an error message and will create a file of zero bytes on the remote resource. You can view a remote file you wish to access, but the attempt to open it will result in the same error. I am aware that there are quite a number of issues concerning AFP access of resources simply inherent in AFP (it is not uncommon to be unable to open on a local host as user X a remote file owned by User Y files, even where one has authenticated to the server as user Y), but I am advised that this problem arises even where Apples WGM has been used and users are authenticated as the same user owning the resource in question. It has also been suggested to me that this is related to an nfslock problem and there has been some discussion of the problem as OOo users who have downloaded the OS X port of OOo 2.x have complained of these isssues on the pertinent forums.
This should apparently be assign to ericb or fheckl
Some information about AFP (Apple Filing Protocol) can be found at http://developer.apple.com/documentation/Networking/Conceptual/AFP/index.html If I understand it correctly it could be reproduced only with two Macs interconnected and some volume shared over AFP which I unfortunately do not have. We probably do not detect AFP specific error code or user rights correctly or something similar.
I can confirm this on two machines running MacOS X 10.4.5 and OpenOffice.org 2.0.2 RC1. Cannot save/ open file on AFP. OO.o says: General input/output error.
1) This is an issue with AFP, and arguably not with the Mac hardware platform or OS, so the issue should be replicatable between and two nodes in which Node A is accessing data over AFP that is shared by Node B. 2) I do have a linux server up and running that has AFP running on it and I endeavor to replicate this error Tuesday where one or both nodes are not Macs and are not running OS X so as to confirm this. 3) The NeoOffice people apparently had a pretty good idea where the problem exists and how to fix the problem.
There is a recently posted (Feb. 6, 2006) suggestion at: http://www.oooforum.org/forum/viewtopic.phtml?t=31367&highlight=afp which argues: ************************* Solved! Here's a tip I found in another forum: Comment out two lines in the soffice file. Right or control click on the application and select Show Package Contents. Double click on Contents and again on openoffice.org2.0. Double click on the program folder and open the file soffice using TextEdit or some other plain text editor. Add comments (#) to the lines which enable file locking so they appear as below. # file locking now enabled by default #SAL_ENABLE_FILE_LOCKING=1 #export SAL_ENABLE_FILE_LOCKING Save the changes and start OOo. Everything should work as expected. *************************** I saw other comments which suggested that this was not a solution including the statements on the OpenOffice Mac support forum (which is at trinity, not at oooforum.) Of course, turning off file locking does not solve the problem, it just means you can now corrupt the subject file ;=} WHile this may be a workaround for short term, I don;t think its a good diea to have all Mac users turning off file locking in ordfer to be able to use OOo
This thread: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=1947 disappeared for a bit asI think it was moved so I could not cite it earlier..... Here is another cites to that forum: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=1928
ericb->net_buoy Thank you for reporting this bug. I already have answered on ac@porting mailing list, and we will try to find a solution. ericb->molcanf With your report, status changed to new Have you the possibility to test with last 2.0.rc1 please ? nfslockroblem is included inside, and should solve this problem. If not, I'll ask nfslockproblem owner.
Created attachment 35037 [details] Use Advisory Locks instead of Byte Range Locking
The patch changes the locking method from Byte Range Locking to Advisory Locking, which is what Apple recomments for MacOS X Applications using the BSD subsystem in http://developer.apple.com/technotes/tn/tn2037.html. BSD Advisory Locking seem to be fully sufficient for OOo's purpose, so it probabl make sense to check other platforms for O_EXLOCK support as well. Works fine for me with afp/smb. BTW: Byte Range Locking seems not even to be implemented for afp/smb (ENOTSUP).
obr: ha! seems you have found the real fix for the locking problems. The code that Patrick donated was checking against ENOTSUP and then ignoring it. So Patricks patch was fixing a symptom, not the real issue. Excellent, now just lot's of testing :)
Is there a patched build we can test. I am not clear on what happens now....
I am going to integrate the patch to CWS macosx20xfixes02 for 2.0.3 - it will most likely show up in 2.0.2 rc5 as well.
Patch commited in CWS macosx20xfixes02.
@tra : can you please verify this issue, so that we finally can integrate macosx20xfixes02 ? TIA.
Issue verified fixed System : local network, with 2 machines Machine 1 : Mac Intel : 192.168.0.1 Machine 2 : Powerbook 192.168.0.2 (machine2) : Using System preferences -> Mac file sharing -> enable Result : it's written : other user MacIntosh can access your computer using AFP://192.168.0.2 The remote Volume must be mounted using the finder ( Go -> connect to server , and choose machine2 ) Process used for tests : File : accented_chars.sxw , located on machine2 from machine1, opening accented_chars : R/W ok, no error -> AFP works. On machine2, opening accented_chars.sxw , already open on machine2 : read only access Little limitation : accented_chars.sxw can be modified, and changes saves only if not open (read only) on machine2
.
*** Issue 60804 has been marked as a duplicate of this issue. ***
Problem is back with MacOS X Tiger: error message " Could not create backup copy". :(
Created attachment 40137 [details] This patch allows to open and lock a file on an AFP share.
Unfortunatly the second patch does not yet resolve the issue of OOo not being able to start from an AFP volume. Error message: the component manager is not available :(.
I have filed issue 70976 for the startup problem on AFP.
obrmac: Great, the patch looks nice :) Excellent that you added a proper comment to it. Just small nit: The comment should be titled "adjustLockFlags", not "getLockFlags" as it is now.
Created attachment 40140 [details] New version of previous patch which adjust's the comment and does not generally change the lock flag to O_SHLOCK. Thanks to Pavel and Mox for their reviews.
Created attachment 40557 [details] Replacing previous fix, which did not work as expected
set target to 2.1.
Fix commited to CWS afplock.
Verified fixed in OOE680_m4 Thanks !
closing ancient issues