bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: dgutov@yandex.ru,  50572@debbugs.gnu.org,  andrewjmoreton@gmail.com,
>   manuel@ledu-giraud.fr
> Date: Thu, 11 Nov 2021 03:56:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We can always use "/\\" as SEPARATORS on MS-Windows, can't we?
> 
> I was wondering about that -- are both of those characters disallowed in
> file name components on Windows?

Yes.  Windows APIs recognize '/' as (another) directory separator, and
so using it in file names is not allowed.

> If so, then yes.  What would be the test to identify the systems
> where this is the case?

 (memq system-type '(windows-nt ms-dos))

> > But if we want a function that returns the "depth" of a file in a
> > filesystem, then it will need to call expand-file-name internally
> > anyway, for the same reason I point out above, right?
> 
> Yes.  This function can be used as a component in that calculation, but
> if that's the purpose of the call, then the caller has to make the file
> name non-relative first.

If we will require the caller to provide an absolute file name, then
why not call expand-file-name internally?  We are not saving anyone
from any potentially expensive operation, because ensuring a file name
is an absolute one without calling expand-file-name is notoriously
hard and unreliable in Emacs.  So in practice, if the requirement is
to provide an absolute file name, the callers will always call
expand-file-name anyway.