> differences on case-insensitive file systems.=C2=A0 Did you really mea=
n
> that?
Indeed, such notions have already been requested and discussed here, and
it's not clear exactly what is needed and when.
I can see several different meanings of "canonical", i.e. represe=
ntative
member of an equivalence class (and I'd be inclined to prefer a functio=
n
that checks for "equivalence" between two file names rather than<=
br class=3D"gmail_msg">
a function that tries to find one canonical name).=C2=A0 The equivalence
classes could be:
- equivalent regardless of the actual on-disk data.=C2=A0 I.e. this can'=
;t
=C2=A0 take symlinks or hard links into account.=C2=A0 Questions remain abo=
ut
=C2=A0 whether it could presume the "normal semantics of the most comm=
on
=C2=A0 file-system".=C2=A0 E.g. should it assume case-insensitive name=
s in
=C2=A0 MacOS/Windows and case-sensitive in GNU/Linux?
You couldn't even do that because ca=
se-folding on Windows depends on the file system. The only possibilities I =
see here are converting backslashes into slashes (or vice versa), and colla=
psing "//" and "/./". You couldn't even collapse &q=
uot;/../" because of symlinks. (Or you could ignore directory symlinks=
, as in=C2=A0
https://golang.=
org/pkg/path/#Clean).
=C2=A0
- equivalent in practice for the current state of the file-system.
=C2=A0 You can test this equivalence by comparing the output of
=C2=A0 `file-attributes', except when the name corresponds to a file th=
at
=C2=A0 doesn't exist (yet?).
Like all filesystem operations, this easil=
y introduces race conditions if decisions are made based on it: What might =
be an equivalent file name now (pointing to the same inode), might not be a=
nanosecond later.
Over all, such an operation sounds more useful=
than it actually is.=C2=A0