bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Torbjorn SVENSSON
Subject: Re: [PATCH] Warn user when 2 files conflict on a case insensitive fs
Date: Sat, 7 Jan 2023 11:28:45 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1



On 2023-01-07 11:21, pertusus@free.fr wrote:
On Sat, Jan 07, 2023 at 11:54:03AM +0200, Eli Zaretskii wrote:
Date: Sat, 7 Jan 2023 10:38:57 +0100
From: pertusus@free.fr
Cc: Gavin Smith <gavinsmith0123@gmail.com>, torbjorn.svensson@foss.st.com,
        bug-texinfo@gnu.org

No, what I would like to know is whether nodes are concatenated when
split, or there is only one node in the output.

Only one node is in the output, AFAICT.  I attach an archive of the
directory created by the command "makeinfo --html split-test.texi",
where split-test.texi is the text you sent with the two lines

   \input texinfo @c -*-texinfo-*-

   @setfilename split-test.info

prepended.

Unfortunate, but expected.  And, as expected the file content
corresponds to the second node, as it is the last file written according
to the code.  With the current code, at least it should not be possible
to have garbled files as Akim described in 2006, but this is not so good
either.

Any idea on what could be done?  My only idea would be, if there file
names that differ only by case to be output, before doing the actual
output do a runtime test to test if the filesystem is case-insensitive,
and if so set CASE_INSENSITIVE_FILENAMES if CASE_INSENSITIVE_FILENAMES
is undef (would be the default).  It would penalize all the runs,
though.

The other option is to change the documentation, tell the users that
texi2any do not try to know if the filesystem is case insensitive and
that if CASE_INSENSITIVE_FILENAMES is not set the files will get
overwritten.


I don't think that texi2any should try to be smart and poke the file system as the file system that the makeinfo command happens to put the output on might not be the final file system and it can have very different properties.

Consider the use-case I mentioned before; build on GNU/Linux, but transfer the files over to a NTFS/FAT/... based file system. What would be the expected behavior here, in your point of view? I, as a user of makeinfo, would expect the files names to be unique and that this problem should not be forwarded to the tools using makeinfo to generate their documentation.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]