Re: [PATCH] Warn user when 2 files conflict on a case insensitive fs

[Patrice Dumas]

On Sat, Jan 07, 2023 at 11:41:36AM +0100, Torbjorn SVENSSON wrote:
> 
> 
> If this is clear that I should have been using the
> CASE_INSENSITIVE_FILENAMES setting, why is it not always active?

Because it produces suboptimal manuals in case sensitive filesystems.

> I, as a user, would expect to have the same documentation generated
> regardless if I happen to run makeinfo on a Windows host or a GNU/Linux
> host. Doesn't that requirement make sense to you?

There needs to be a balance between producing filesystem independent
manuals and poducing best manuals.  In the default case, we prefer to
produce the best possible manuals.  However, you can always set
CASE_INSENSITIVE_FILENAMES if you value more manuals that are better
suited for case-insensitive filesystems.

> > Indeed, I think that it should be in a more specific place, stating
> > something clearer about redirection file, for instance that a
> > redirection file cannot be created for @node XX because @anchor YY (or
> > @float label) is already associated to that redirection file.  Another
> > even more involved solution would be to remove the automatic redirection
> > when there are two nodes redirected from a redirection page, and only
> > leave the text for the user to click on.  Or use javascript to do the
> > redirection, and without javascript there would be a need to click on
> > the appropriate link.
> 
> I can buy the idea of not having an automatic redirect in the case of a
> conflict. Would you like me to try to write a patch for that scenario?

That'd be nice, indeed.  Beware that the issue can happen between
redirection pages, and also between regular elements and redirection
pages (but not between regular elements).

> In the newlib case, there were a chapter (Iconv.html) and a node
> (iconv.html) and the solution that "fixed" the problem was to rename the
> chapter. I suppose this is also a problem in the current implementation of
> text2any as it's simply pushed to the user to resolve rather than having the
> tool generate unique filenames/aborting in the case of conflicting
> filenames.

I do not think that the tool is to blame (after the bug is fixed, of
course ;-), the decision is to blame.  But there is no decision that
is not pushed to the user as there are conflicting choices without a
an option that is better in all cases.  If the default was
CASE_INSENSITIVE_FILENAMES=1, all the users who want the best manuals,
on case-sensitive filesystems would have to override the default.

-- 
Pat