bug#61901: 30.0.50; [PATCH v3] Add safe-local-variable-directories variable.

[Antero Mejr via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> diff --git a/doc/lispref/variables.texi b/doc/lispref/variables.texi
>> index b3a8cd8110c..28deddf985d 100644
>> --- a/doc/lispref/variables.texi
>> +++ b/doc/lispref/variables.texi
>> @@ -1986,7 +1986,7 @@ fully-expanded absolute file names that end in a
>> directory separator
>>  character.  They may also be remote directories if the variable
>>  @code{enable-remote-dir-locals} is set non-@code{nil}.  Directories in
>>  this list are matched case-sensitively, even if the filesystem is
>> -case-sensitive.
>> +case-insensitive.
>>  @end defvar
>
> This actually means that I misunderstood the code.  Now that I see the
> truth, why is it a good idea to compare directories case-sensitively
> when the filesystem is not?  That's not something users will expect.

What if a directory's case sensitivity changes so that it previously did
not match, but now does? This could happen with Windows per-directory
case sensitivity modifications, mounted disks, or remote paths.

To accurately assess if a directory name matches with possible
case-sensitivity, the process would be:
1. check the case-sensitivity of the filesystem
2. If case insensitive, check the case-sensitivity of each subdirectory
(using Windows queryCaseSensitiveInfo if applicable)
3. map over the components of the directory name, checking each subdirectory
with the correct case-sensitivity setting

That logic would be difficult for users to reason about, so for features
with security considerations like this I think it's better to err on the
side of safety and simplicity even if the behavior is stricter than
expected.