Proposed resolution:

This wording is relative to N4640.

1. Make the following edits to [fs.op.equivalent]:

   bool equivalent(const path& p1, const path& p2);
   bool equivalent(const path& p1, const path& p2, error_code& ec) noexcept;
   

   -1- Let s1 and s2 be file_statuss determined as if by status(p1) and status(p2), respectively.

   -2- Effects: Determines s1 and s2. If (!exists(s1) && !exists(s2)) || (is_other(s1) && is_other(s2)) an error is reported (27.10.7).

   -3- Returns: true, if s1 == s2 and p1 and p2 resolve to the same file system entity, else false. The signature with argument ec returns false if an error occurs.

   -4- Two paths are considered to resolve to the same file system entity if two candidate entities reside on the same device at the same location. [Note: On POSIX platforms, tThis is determined as if by the values of the POSIX stat structure, obtained as if by stat() for the two paths, having equal st_dev values and equal st_ino values. — end note]

   -?- Remarks: !exists(p1) || !exists(p2) is an error.

   -5- Throws: As specified in 27.10.7.

[ 2017-03-04, Kona ]

Set priority to 0; Tentatively Ready

See discussion on the LWG mailing list with subject "Is equivalent("existing_thing", "not_existing_thing") an error?", abreviated below:

Billy O'Neal:

The existing "an error is reported" effects say that an error is reported for !exists(p1) && !exists(p2), but I'm not sure that treating equivalent("existing_thing", "not_existing_thing") as "false, no error" makes any more sense than for equivalent("not_existing_thing", "not_existing_thing").

It's also unfortunate that the current spec requires reporting an error for is_other(p1) && is_other(p2) — there's no reason that you can't give a sane answer for paths to NT pipes. (Do POSIX FIFOs give garbage answers here?)

Davis Herring:

I'm fine with an error if either path does not exist. See also Late 29: I would much prefer

file_identity identity(const path&, bool resolve = true);

which would of course produce an error if the path did not exist (or, with the default resolve, was a broken symlink).

See Late 30 and 32 (31 has been resolved). FIFOs pose no trouble: you can even fstat(2) on the naked file descriptors produced by pipe(2). (That said, I observe the strange inconsistency that Linux but not macOS gives both ends of a pipe the same st_ino.)

POSIX has no reason that I know of to treat any file type specially for equivalent().

Billy O'Neal:

I think such a file_identity feature would be useful but we can always add it in addition to equivalent post-C++17.

Beman Dawes:

Looks good to me. Maybe submit this as an issue right away in the hopes it can go in C++17?