On Sun, 17 Mar 2002, Jan Harkes wrote:
> Interesting, I ran the 'SO:Coda User:ext2' combination successfully.
It might have been other kernel/glibc combination?
> > [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
> getdents(64) is supposed to return '0' when there are no more directory
> entries. It look like we returned an entry with an empty name, or we
> didnt return the name that it was expecting.
I was too quick to conclude it was a coda-glibc error.
Anyway, it looks like soffice gets some data it can't cope with.
> The generic VFS layer handles all that stuff. s_maxbits is set to 32 and
> it should automatically do all translations. The only 'differences' are
> that you can't seek, read, or write past the 2GB file limit.
As I haven't seen the accesses to the "missing" file, I can think that
it is getdent*() that breaks... Hmmm, somebody on the list who could test
it under similar or different conditions?
Not that I am missing StarOffice so much but it doesn't feel good that it
breaks on Coda.
(it is "broken" though in other ways - e.g. its initial ./setup ignores
LD_LIBRARY_PATH while looking for xlibs, kind of shooting itself into the
foot :)
(soffice leaks file descriptors, too...)
Regards,
--
Ivan
