Stefan Monnier <
address@hidden> schrieb am Mo., 12. Sep. 2016 um 22:09 Uhr:
> Using string= here will cause false negatives, e.g. with Windows file
> names that use backslashes vs forward slashes, or due to letter-case
> differences on case-insensitive file systems. Did you really mean
> 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. representative
member of an equivalence class (and I'd be inclined to prefer a function
that checks for "equivalence" between two file names rather than
a function that tries to find one canonical name). The equivalence
classes could be:
- equivalent regardless of the actual on-disk data. I.e. this can't
take symlinks or hard links into account. Questions remain about
whether it could presume the "normal semantics of the most common
file-system". E.g. should it assume case-insensitive names in
MacOS/Windows and case-sensitive in GNU/Linux?
You couldn't even do that because case-folding on Windows depends on the file system. The only possibilities I see here are converting backslashes into slashes (or vice versa), and collapsing "//" and "/./". You couldn't even collapse "/../" because of symlinks. (Or you could ignore directory symlinks, as in
https://golang.org/pkg/path/#Clean).
- equivalent in practice for the current state of the file-system.
You can test this equivalence by comparing the output of
`file-attributes', except when the name corresponds to a file that
doesn't exist (yet?).
Like all filesystem operations, this easily 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.