Re: [porting-dev] May be bug on Open Office 2.0

[Oliver Braun]

Hi Mox,

Mox wrote:
If the enabling of file locking is really the culprit for not being 
able to use networked filesystems, I'd really recommend disabling 
locking by default for official/public OSX builds.

This would also disable file-locking for local machines, exposing all 
users to the risk of data loss (again).


In my view this is regression from OOo 1.1 and locking should not be 
enabled before it works with networked volumes also.

It is not clear yet who to blame for this: OOo uses an official API for 
file-locking, so either we have a bug in our implementation (e.g. not 
handling error codes correctly) or the implementation of the network 
filesystem (on the server or the client) has a bug - or both.

I also think we have to destinguish between home directories being 
exposed by a server and dedicated shared volumes: for the latter I would 
not recomment a network file system which does not support file locking 
(which seems to be the case for AFS).

Regards,
Oliver


       Mox

On 12/7/05, *Stephan Bergmann* < [EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:

    GB wrote:
    > Hi,
    >
    > This may be a bug with Open Office 2.0 ?
    >
    > $ uname -a
    > Darwin R-PUNIX-MAC-OSX-BECHE018.local 8.3.0 Darwin Kernel
    Version 8.3.0:
    > Mon Oct  3 20:04:04 PDT 2005;
    root:xnu-792.6.22.obj~2/RELEASE_PPC Power
    > Macintosh powerpc
    >
    >
    > On the file here, you can see that I didn't succeeded in working on
    > remote disks. The error message says there is an input/output error.
    >
    >  It's impossible to open or to save a file on a remote disk.
    > Nevertheless the file is created on the remote disk, with the
    good name,
    > but it is empty. On the error message Ooo speaks about a file "sans
    > nom1", althought I gave it, a name.
    >
    > On my local disk all is OK.
    >
    > I work in a large company, 100% Windows and Office Microsoft ; So I
    > tried to face the dictatorship with my Macintosh, but we work
    primarily
    > on data distributed on remote disks :  I cannot thus, use Ooo
    because of
    > this error.
    >
    > Ooo is great. Congratulations for this very great work.
    >
    > Guy Béchet
    >

    From the "general i/o error" in your screenshot, and just a wild
    guess:
      Could it have anything to do with NFS and file locking (see issue
    54586)?  If your remote access is via NFS, and if OOo on Mac uses file
    locking as it does on Linux and Solaris (I have no idea), you
    could try
    the following:  In the soffice script (in OOo's program directory),
    comment out the lines

       SAL_ENABLE_FILE_LOCKING=1
       export SAL_ENABLE_FILE_LOCKING

    by prefixing them with '#'.  (If there are no such lines, it probably
    means that OOo on Mac does not use file locking...)

    -Stephan

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    For additional commands, e-mail: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>




--
Mox on G 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]