> The binaries worked OK under SCO ODT 3. On OSR5, I get phenomena like
> a) isql not able to see all *.sql files in current directory
> (28 exist: it sees 25)
> b) r4gl not able to see all *.4gl files in current directory
> (5 exist: it sees 3)
> All the files in question are 777, same owner, same group.
> Granted that nobody said that 4.x was binary compatable with OSR5, I
> am suprised (I'm probably naive) that these programs can't read the
> current directory reliably.
> Does anybody think that there should have been a way to write their
> interface portably ?
> My filesystem type is HTFS.
The directory format of HTFS is different from the earlier S51K and EAFS
filesystem formats. Yes, there is a fine portable way of accessing
directory information, which all applications *should* be using.
However, in the real world, some don't. I don't know whether Informix
4.x is such an application, but let's assume for the moment that it is.
The filesystem drivers in SCO OpenServer Release 5 can recognize an
"old" application which attempts to read directory entries the old way
(by parsing the directory data itself). The filesystem contrives to
present the data in the old S51K directory format. What you're
describing makes it sound like this is *almost* working.
We recently discovered a bug in how the directory translation is
implemented. An application which blindly reads data from the directory
will be fooled. If it first does a stat() on the directory to determine
how much data to read, it'll get the directory's size in terms of its
native HTFS format. That size will be different than it would have been
in S51K format. If the HTFS size is smaller, some of the files in the
directory will be missed. BTW, you can make a rough estimate of the
"S51K size" of the current directory by doing: `ls -a | wc -l` and
multiplying the result by 16. The "HTFS size" is as shown by ls: `ls
-ld .`. The translated S51K format uses 16 bytes for each entry and
truncates filenames longer than 14 chars, so you can differentially bulk
up the HTFS size by creating very long filenames.
To test whether this is the problem, create several extra files in the
directory (with long filenames -- here_is_a_junk_file_with_a_long_name.1
through 10, for example). Then see if Informix finds all of its files.
The other thing you could do is to create an EAFS filesystem on which to
store the Informix data files. Note that the same filesystem driver is
used to operate EAFS and HTFS filesystems, under Release 5. This means
that EAFS filesystems get the same logging, checkpointing, etc. benefits
as HTFS. HTFS features which are not available with the EAFS filesystem
format are: versioning/undelete; >64K inodes; >2GB filesystem size;
in-inode symbolic links.