OOo 2 will not work at present over afp because of code

[net-buoy]

I just wanted to confirm that OOo2.x will not be able to access storage mounted via AFP at this time due to issues with the underlying code.
My experience is that you will get an error message trying to save to a remote resource and when you look you will find a zero byte file. While you will be able to see files on your remote resoruce you will also be unable to open those resources with OOo2.x

It is suggested that OOo 2 will work on Macs across NFS, even to Mac servers.

Lastly, it is represented that the current version of NeoOffice does not suffer from the AFP shortcoming.

Since it might be considered common for a user deploying Macs to be using AFP, I think it would also be appropriate to suggest to the OOo folks that a caveat to that effect should be published on the download page.

[ericbachard]

ericb->net-buoy

Please, verify before to post such informations : A child Workspace called "nfslockproblem" is scheduled for 2.0.2 -means will be integrated- , and I think the nfs problem will be fixed.

If not, I'll personnaly reopen the corresponding issues.

--
Eric Bachard

[ovvldc]

[ericbachard]

ericb->Oscar

To be fair, nfslockproblem is not my cws. I found it loooking at EIS changes very randomly.

--
Eric Bachard

[jjmckenzie51]

[LemonAid]

[net-buoy]

three points:

1) I just received a note from eric hoch suggesting that OO is aware that there may be an NFS issue, but has not been able to confirm the AFP issue. I am sending him the URL of this thread....

2) WHile from the perspective of the program internals an NFS issue may be related to an AFP issue, that is not necessarily the case.

3) The forum seems to indicate that others have beeen able to access remote resources via NFS. In fact I was looking at that as a short term solution. I guess it is now less clear to me what the issues actually are (and the reason I started a separate thread is to try and bring clarity to the issue.)

I think just about everyone would agree that being unable to support a platform's native file sharing protocol might be seen as a "show stopper" , no matter what your position is in developing OO or NO.

The question I think for those looking to use either programs is what currently works and what does not. For example, I assumed that when I was told that NeoOffice 1.2 would read odt it would also write odt, but that was a poor assumption on my part.

So it would be helpful if it was clear that a) AFP does not work, and if this is somehow associated with an nfslock isssue, whether the problem also effects access of remote resources via NFS.

I want to thank one and all for the work on both products....

[jjmckenzie51]

[ovvldc]

[jjmckenzie51]

[jakeOSX]

to go back to the original poster (i also read the letter that was posted to the mailing list)

is ODT a requirement?

If not, I would suggest using NeoOffice 1.2 for now (remember, sxw files are not closed source, they are just OO.o file formats.) it would be able to open files over the network. And when 2.0 comes out, it will read sxw and ODT files.

If it is, then hang out for a bit, Neo 2.0 should alpha in a few months (maybe get by on either oo.o 2.0 or Neo 1.2 til then?).

[jjmckenzie51]

[net-buoy]

This post is becoming, should I say helical, which may be part of the underlying issue.... I want to add some points that are probably out of place in a testing forum and then return to the testing issue....

First.... short term solution for us would seem to be turning off filelocking if that indeed resolves the problem as the files in question are not shared. I will test that as others appear to confirm this works. But is this germane to this forum (or maybe the question to ask is, where should such matters be discussed....) I wanted the ability to read and write odt because we are also rolling out linux systems using OOo 2.0 and I would like tpo propose to TIC (those in charge) that we replace MS Office with OOo... explaining that NeoOffice 1.2 may or may not be OOo, well that's not a conversation I want to have.....

Second.... not being someone particularly enamored of the Mac (which now is "built on" *nix and will be using Intel chips) I thought having an X11 app that was well behaved and provided office suite functionality was the "cat's meow"... I still do.... For virtually all the users where I work (some 7000) I think a $300 linux box with OOo and mozilla clients is a much better fit..... Again, this isn't germane here.

Third and perhaps a little closer to the point, there was a comment posted somewhere that argued that the AFP problem was related to an OS file-locking issue that was resolved in linux 2.6 cores but is extent in Darwin. The initial problem I tried to address was that for someone using AFP, a discussion of NFS issues is arguably not relevant.... this confusion is compounded by the fact the discussion of such matters is here on trinity, and not on oooforum

Fourth, there is some internal dissension, if that is correct term. The forums include postings that Patrick already fixed this once and someone should just ask him to fix it in the other code base, that this is known issue and schedule for a fix in 2.0.2 (the Mac download page indicates we are at 2.0.0rc3, though the OOo page suggests that you are downloading 2.0.1) etc, but in no case are we I think at an RC where the port does not support the OS's native file sharing protocol, which from a Mac user standpoint is Apple's protocol, for good or ill. [and for those who would argue we should be using NFS, I have to reply that they are right, but the object of that observation should in the first instance be Microsoft....]

Someone pointed out, and I want to reiterate, that from the standpoint of a user, the belief that a solution to problem A is imminent may be at least a couple of beers away from the solution to problem B ;=}

I guess my underlying problem, which has been beat to death but I think lies unresolved, is that it seems to me that a variety of posters have complained about OS X file sharing issues for months, whether its the type posted by I think Kopanda and myself, or the issue where one is trying to run OOo with a roaming profile, which has, as its essence, an AFP mounted home directory. The reason I tried to perhaps make this into a mountain from a molehill is because this is a critical issue for networked Mac users (I thank one of the erics for the phrase "show stopper") and the forum discussion seemed, well , unfocused in some respects.

I am gratified by the response however, so than you one and all for taking the time to address this.

But to return to testing, the data, such as has been offered, are not necessarily categorical, i.e. it is at least unclear to me still in which specific cases this problem appears.

a) For my part I can attempt to run a test of the first 2.x RC against Netatalk (AFP) Tuesday. However, since I am unaware of the details of the underlying nfslock issue I don't know if this will be helpful or not. I will also attempt the file locking work around to confirm that this resolves the error in one or both cases. Lastly, I will try to run a test of a 10.4.4. workstation as against another 10.4.4 workstation. I will do this with the currently available RC unless someone would like me to do it with some other version. If people think this is a waste of time I will not do it at all.

b) I can tell you that running the first 2.x RC on 10.4.3 as against an Apple OS X server of unknown vintage results in the error, However, as I have also noted, OS X server installations have known idiosyncracies (i.e. if you log in to Node A as localuserA and authenticate to remote Node B as remotenodeuserB, there is a significant possibility that you will be denied rights to the remote files.) We also have some postings that suggest that various Mac hosts against other various Mac hosts don;t produce an error.... As a result I cannot say with any surety where the problem is and I think to be fair to developers, unless this can be tested in lab conditions (i.e. a MAC lab) this could be a rather difficult problem.

[jakeOSX]

some things to keep in mind. please remember that there is no official 'version' of openoffice.org for the mac. there are two ports of openoffice.org for the mac. the difference is this. the big openoffice.org machine puts together, tests and improves the versions for linux, windows and solaris. then, a handful of dedicated, underappreciated programers work to make either the X11 version or the NeoOffice version. unfortunatly what this means is that while most of the program works, sometimes there are things that linux or windows can do that a mac version cannot.

ok, now to the issue at hand. let's forget ODT for a few minutes. does NeoOffice 1.2 do what you need it to do? (if you don't know, could you check?) if it does, then the issue with 2.0 (either Neo of OO.oX11) is being worked on, and one of them should have a solution soon.

if neo does NOT do what you need it to do, then you need to file a bug, either here, or with the OO.oX11 group. that way the problem can be known, assigned, etc.

As for now, the main reason i suggested Neo (this was assuming it worked) was this: first, if you have been a MS office place for a while, i'd wager most of your files are still in MS format. Neo can read ODT, but would have to save in SX*, or MS format, both of which are easy to read by any version of OO.o.

The other option is to install OO.oX11 as local installs, and have the users move the files to their computers before working on them.

I hope all of this helps.

[LJHeal]

My solution was to bring all of the files Ooo2.0.2 needs local. Easy as plugging a server disk into a Firewire port. But there is only the one Macintosh in the PC sea...

It is a permissions problem, if i recall right. There must be a simple way to arbitrate or filter permissions. You can always, ahem, log in as root.

The same problem happens if you want to use Samba to access CFS files over the network. But the good news is that the same Samba will share files out over that network and you can impose selective user-level access on them.