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
