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