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.
