Hello!

Here follow my promised experiment results:

I have setup English StarOffice 5.2 ("nfs" locking OFF) on Linux 2.4.17,
glibc 2.2.5 and rather recent Coda (patched 5.3.17) and tested it in 4
combinations:

StarOffice, its installation tree (after "setup /net" made on a local
file system while lying to it that it is under /coda/....) :
on Coda  -  on  local ext3

User, her homedir :
on Coda  -  on local ext3

-----------------------------------------
StarrOffice     User      It works
-----------------------------------------
ext3            ext3      YES
Coda            ext3      NO
ext3            Coda      NO
Coda            Coda      NO

The (only) problem I observed during all experiments:

user setup goes well and creates all the needed file structures,
but soffice complains about not finding $HOME/office52/user/sofficerc,
despite that it *is* in place.
(in fact, no traces of any access to "sofficerc" in strace logs, but see
below)

No crashes.

One suspicious thing I see in the strace logs:
----------------------------------------------
[pid  4426] getdents64(0xc, 0x80e38b0, 0x2000, 0x2) = 216
[pid  4426] getdents64(0xc, 0x80e38b0, 0x2000, 0x2) = 0
[pid  4426] open("", O_RDONLY)          = -1 ENOENT (No such file or
directory)
[pid  4426] fcntl64(-1, F_GETFD)        = -1 EBADF (Bad file descriptor)
[pid  4426] open("", O_RDONLY)          = -1 ENOENT (No such file or
directory)
[pid  4426] fcntl64(-1, F_GETFD)        = -1 EBADF (Bad file descriptor)
[pid  4426] open("", O_RDONLY)          = -1 ENOENT (No such file or
directory)
[pid  4426] fcntl64(-1, F_GETFD)        = -1 EBADF (Bad file descriptor)
----------------------------------------------

It looks like libc tells staroffice that getdents64() succeeds,
but it returns garbled information.
(I wouldn't be surprised if a program crashed with such data :-)

Jan, is it possible to make Coda cooperate with glibc?

http://www.suse.de/~aj/linux_lfs.html   states:
-------------
Coda: Does not work with LFS (Large File Support) - local cache issues,
protocol is ok.
-------------

I see two options: make that xxx64() system calls fail in a consistent way
or make them to work :)

Best regards,
--
Ivan