bug#21816: elisp-mode-tests fails on a case-preserving filesystem

[Stephen Leake <stephen_leake@stephe-leake.org>]

I've now looked at the definition of `file-equal-p':

  (let ((handler (or (find-file-name-handler file1 'file-equal-p)
                     (find-file-name-handler file2 'file-equal-p))))
    (if handler
        (funcall handler 'file-equal-p file1 file2)
      (let (f1-attr f2-attr)
        (and (setq f1-attr (file-attributes (file-truename file1)))
	     (setq f2-attr (file-attributes (file-truename file2)))
	     (equal f1-attr f2-attr))))))

This implies there are two reasons why `file-truename' (and by extension
`file-canonical-name') is not sufficient for determining if two names
identify the same file.

I think one issue is hardlinks; a file can have two distinct truenames
because of hardlinks, but the attributes contain the uid and the inode
number, which will identify the actual file.

I'm not clear on why a special handler for file-equal-p is needed; is
that just an optimization? file-truename respects file handlers.


This changes Option 2 as indicated below.

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> To summarize:
>
> The problem is comparing xrefs directly (for sorting and testing),
> comparing the result of xref-location-group (for sorting), and possibly
> comparing results of other xref access functions in the future. Note
> that any filenames in xrefs identify existing files, except in
> artifically constructed tests.
>
> I believe the two alternatives being proposed are:
>
> 1) Use `file-equal-p'
>
> - Provide a cl-defgeneric `xref-location-equal-p' for the root
>   xref-location type.
>
> - For each type that inherits from xref-location, provide an
>   implementation of `xref-location-equal-p' that uses `file-equal-p' for
>   each file name.
>
> - Provide a cl-defmethod `xref-equal-p' for the root xref type that uses
>   `xref-location-equal-p' for the location.
>
> - For each type that inherits from xref, provide an implementation of
>   `xref-equal-p' that uses `xref-location-equal-p' for each location.
>
>
> 2) Use `file-canonical-name'

This changes to "Use `file-truename'.

> - A canonical file name has the following features:
>
>   It contains forward slashes for directory separators.
>
>   If the file name identifies an existing file, the canonical file name
>   casing matches the actual file name casing. If not, the case of the
>   portions of the canonical file name that do not exist is arbitrary.
>   Note that this matters only on case-insensitive file systems.

I believe this is true of the result of file-truename, and it could be
added to the docstring for that function.

The following two points cannot be satisfied in the presence of
hardlinks, and possibly other issues with file handlers; so they are deleted.

>   Two different non-canonical names for an existing file convert to the
>   same canonical file name. Note that this means symlinks are resolved.
>
>   Canonical file names may be compared with `string-equal' and
>   `string-lessp'.

> - Provide a system-dependent `file-canonical-name' that converts
>   user-provided file names to a canonical file name.

This is deleted.


> - Require each variant of make-xref-location to use it for file name
>   slots.

"it" now means "file-truename".

> Option 1) solves the problem of comparing xrefs and xref-locations, but
> does not solve the problem of comparing results of
> xref-location-group.

This remains true. And since xref--analyze compares the result of
xref-location-group, it is not just a theoretical problem; I provided an
example where it fails.

> Option 2) solves the problems of comparing xrefs, xref-locations,
> results of xref-location-group, and results of future xref access
> functions.

This is true only if there are no hard links (or other issues with file
handlers). 

> So far, `file-truename' seems adequate for `file-canonical-name', but it
> might be best to define the alias, in case we find problems in the
> future.

This is not true; I'm now convinced it is not possible to define a fully
correct `file-canonical-name'.

Hmm. If there is a way to iterate all the truenames for a file (I didn't
find one), then we could order them with string-lessp, and simply take
the first as the canonical name. I'm not sure that would be really
useful.

> Option 2) seems better to me. 

This remains true. If there are hardlinks on the disk, users will just
have to be aware of that, and cope. That's no worse than the current
situation.

-- 
-- Stephe