Behaviour of kpsea re symlinks to directories

[Karl Berry]

    IIRC, we can get just the names of the files in a dir ....

Yes. opendir()... readdir()... closedir()... gets you the names of the
"directory entries" (struct dirent).

    faster than getting all info I would get by doing ls -l ?

Yes. You have to make a separate system call to stat(2) to get the file
type (regular file, symlink, ...), size, etc.

    And the ls-R cache is to even avoid fetching that 
    list of names from the filesystem each time, to get even more performance.

Yes again. Because of I/O caching at every level, reading a single file
is much faster than traversing a directory structure, even if the total
number of bytes of data (all the files' names) is basically the same.

    My TEXMFLOCAL is /opt/yann/texlive/texmf-local (and it has !! in the 
    ...
    Putting a symlink to a file works after mktexlsr (ie. mktexlsr indexes it).

Oh, good. Indeed, I see now that mktexlsr boils down to running "ls -LRa",
and the -L dereferences symlinks (recursively). I'd forgotten that.

    In fact I feel that the current behaviour brings a significant
    performance improvement when dealing with a folder that has no
    subfolder but a lot of files.

Right. That's one of the reasons to do the st_nlink check.  The other
reason is even more applicable to a giant tree like texmf-dist: if there
are zillions of "leaf" directories, even if most leaf dirs are not big
in themselves, it is a significant improvement not to stat() the entries
in all those leaf dirs. This is exactly our case.

    Attached is what happens when doing
    kpsewhich thing2.sty

Thanks.

Since the st_nlink check isn't relevant for !! trees, and the only
non-!! tree (in the default configuration) is TEXMFHOME, and TEXMFHOME
is rarely so huge as to matter, I'm coming to the conclusion that I
should turn the check off by default, and make it controllable by a
texmf.cnf variable. That way anyone who needs the check can get it, but
the "create a dummy directory" requirement would in general go away.

I'm occupied with non-computer things this week, and the binaries won't
change before next year anyway, but I'll get back to this in due time.
Thanks much for bringing this up. --best, karl.