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

[Gavin Smith]

On Fri, Jan 06, 2023 at 08:47:52PM +0100, Patrice Dumas wrote:
> On Fri, Jan 06, 2023 at 01:28:04PM +0100, Torbjörn SVENSSON wrote:
> > Hi,
> > 
> > I can't find where to send patches, so pardon me if this is the wrong
> > channel.
> 
> It is the right channel.
> 
> > I recently noticed a problem doing a building GDB for Windows on a
> > GNU/Linux host. The documentation contains 'qMemTags' and 'QMemTags'
> > and as GDB is using the --split-size argument, the --node-files is
> > automatically activated and a bunch of redirect files are generated,
> > including qMemTags.html and QMemTags.html. As these 2 files have the
> > "same" filename on Windows, the content of one of them will be used,
> > but it's unpredictable witch one. So, to make the developers aware
> > of this situation, I added a simple warning to makeinfo about the
> > potential problem for case insensitive file systems.
> 
> I recall some discussion on this list, and I remember that the end
> result was that it was not a good thing to consider something special
> on platforms that have case sensitive filesystems. One possibility would
> be to have the warning emitted conditionally on having the
> CASE_INSENSITIVE_FILENAMES customization variable set.  With that setup,
> also, I think that the warning will be emitted only in case of a conflict
> between a redirection node and another file, conflict among normal file
> output will be silenced because the nodes will simply be appended
> without trying to open a new file.

I agree, it would be fine to have warning if more than one node/"output
unit" actually gets appended to an output file because of
CASE_INSENSITIVE_FILENAMES.

The manual seems to imply that CASE_INSENSITIVE_FILENAMES does not
need to be set by the user if the file system is case insensitive.  If
that is true, then the following shouldn't happen:

> As these 2 files have the "same" filename on Windows, the content
> of one of them will be used, but it's unpredictable witch one.

It shouldn't happen that the output is lost for the contents of
one of the files - all the output should be present in the file.
Can we confirm what is actually happening?


> There are some issues with the patch, I think.
> * the warning messages comes somewhat too late, there is not much
>   information on the node or nodes conflicting, it is up to the user
>   to find out which nodes are in clonflict.  Maybe this check should
>   be done before, and even quite early, after the determination of the
>   file names, but before any actual output.  Maybe after the call of
>   _set_root_commands_targets_node_files and only if NODE_FILES is set.

Maybe in Texinfo::Convert::Converter::set_tree_unit_file or
Texinfo::Covert::HTML::_html_set_pages_files.  The following in the
latter function already keeps track of how often an output file
is used:

    $self->set_tree_unit_file($tree_unit, $filename);
    my $tree_unit_filename = $tree_unit->{'structure'}->{'unit_filename'};
    $self->{'file_counters'}->{$tree_unit_filename} = 0
       if (!exists($self->{'file_counters'}->{$tree_unit_filename}));
    $self->{'file_counters'}->{$tree_unit_filename}++;

I haven't investigated it but I suspect this counter only goes above
1 if there is the case-insensitive filename issue, in which case
a warning could be issued that multiple "tree units" are being
concatenated in a single file.