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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 11 May 2023 21:11:52 +0300

> From: Antero Mejr <[email-masked]>
> Cc: [email-masked]
> Date: Thu, 11 May 2023 17:49:50 +0000
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > 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.

We already have all that in file-equal-p.  We should just use is
there.