[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add a predicate for canonical file name

From: Philipp Stephani
Subject: Re: Add a predicate for canonical file name
Date: Tue, 13 Sep 2016 06:54:04 +0000

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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]