Proposed Resolution of C++17 National Body Comments for Filesystems(R2)

US 55; 27.10.8.4.5 [path.modifiers] ¶11: replace_extension()'s use of path as parameter is inappropriate
Status: Accept with modifications ✓

The SG believes path is the appropriate parameter type, but that the standard needs to clarify class path usage.

Change 27.10.8 [class.path] ¶1:

An object of class path represents a path (27.10.4.17) and contains a pathname (27.10.4.18). Such an object is concerned only with the lexical and syntactic aspects of a path. The path does not necessarily exist in external storage, and the pathname is not necessarily valid for the current operating system or for a particular file system.

US 56; 27.10.8.4.5 [path.modifiers] ¶11.2: Remove replace_extension()'s conditional addition of period
Status: Reject ✓

Nico presented this to the Library Evolution Working group in Issaquah, including a number of examples (See Nico's Filesystem: Filename Issues slides on the Issaquah LEWG wiki.) There was no consensus for change; the vote was 3/3/3/7/2. See the Issaquah LEWG notes.

US 57; 27.10.8.4.8 [path.compare] ¶2: On Windows, absolute paths will sort in among relative paths
Status: Reject ✓

Insufficient motivation for change.

US 58; 27.10.8.4.9 [path.decompose] ¶5: parent_path() behavior for root paths is useless
Status: Accept with modifications

Resolved by US-77/CA-6

US 59; 27.10.8.4.9 [path.decompose] ¶6: filename() returning path for single path components is bizarre
Status: Reject ✓

path is filesystem's vocabulary type for both full paths and for path components, in the same sense that std::string might be used as the vocabulary type for both sentences and the words in the sentences. See US 55 for further discussion.

US 61; 27.10.8.4.9 [path.decompose] ¶8: Leading dots in filename() should not begin an extension
Status: Accept with modifications ✓

Nico Josuttis presented this to the Library Evolution Working group in Issaquah, including a number of examples (See Nico's Filesystem: Filename Issues slides on the Issaquah LEWG wiki.) Support was unanimous. See the Issaquah LEWG notes.

Resolved by stem() and extension() changes in US-74/CA-3

Nico presented the following cases; the only change from the TS is for the ".profile" case:

path p	p.stem()	p.extension()
"/foo/bar.txt"	"bar"	".txt"
".profile"	""	".profile"
".profile.old"	".profile"	".old"
"..abc"	"..abc"	""
"...abc"	"...abc"	""
"abc..def"	"abc."	".def"
"abc...def"	"abc.."	".def"
"abc."	"abc"	"."
"abc.."	"abc."	"."
"abc.d."	"abc.d"	"."
".."	".."	""
"."	"."	""

US 62; 27.10.8.4.9 [path.decompose] ¶11: It is important that stem()+extension()==filename()
Status: Accept with modifications ✓

Resolved by change to extension() in US-74/CA-3

US 63; 27.10.8.4.11 [path.gen] ¶1: lexically_normal() inconsistently treats trailing "/" but not "/.." as directory
Status: Accept with modifications

Resolved by US-37 and the change to [path.gen] in US-74/CA-3.

US 185; 27.10.7 [fs.err.report]: Fold error_code and non-error_code signatures into one signature
Status: Reject ✓

Does not handle one signature being noexcept(true) and the other noexcept(false), and many other problems. Even the submitter is no longer in favor. See LWG mailing list thread "[filesystem] US-185 Eliminating dual signatures for operational functions", October 25, 2016.

FI 14; 27.10.12.3 [directory_entry.obs]: directory_entry comparisons are members
Status: Reject ✓

This is LWG issue 2761, which has been closed as NAD.

US 73, CA 2; 27.10.8.1 [path.generic]: root-name is effectively implementation defined
Status: Accept with modifications ✓

Change [path.generic]:

root-name:
An operating system dependent name that identifies the starting location for absolute paths. [ Note: Many operating systems define a name beginning with two directory-separator characters as a root-name that identifies network or other resource locations. Some operating systems define a single letter followed by a colon as a drive specifier – a root-name identifying a specific device such as a disk drive. —end note ]

Add a new paragraph at the end of [path.generic]:

US 74, CA 3; 27.10.8 [class.path]: The term “pathname” is ambiguous in some contexts
Status: Accept with modifications ✓

The proposed resolution of this National Body comment enables the resolution of many other filesystem NB comments.

Discussion:

Many operations on filesystem::path are defined in terms of its exposition-only pathname member, which is defined implicitly by path::native() as the native format path. However, the native format need not be compatible with lexical operations like, for example, path::root_name() and path::extension().

This same concern was also raised by P0430R0 Section 2.1, which provided additional rationale.

Proposed resolution:

Remove In the [class.path] synopsis, remove the private (exposition-only) member from class path:

private:
  string_type pathstring; // exposition only

Change [path.fmt.cvt]:

[ Note: The format conversions described in this section are not applied on POSIX- or Windows-based operating systems because on these systems:

— The generic format is acceptable as a native path.
— There is no need to distinguish between native format and generic format in function arguments.
— Paths for regular files and paths for directories share the same syntax.

—end note ]

Function arguments that take character sequences representing paths may use the generic pathname format grammar (27.10.8.1) or the native pathname format (27.10.4.11). If and only if such arguments are in the generic format and the generic format is not acceptable to the operating system as a native path, conversion to native format shall be performed during the processing of the argument.

[ Note: Some operating systems may have no unambiguous way to distinguish between native format and generic format arguments. This is by design as it simplifies use for operating systems that do not require disambiguation. An implementation for an operating system where disambiguation is required is permitted to distinguish between the formats. —end note ]

If the native format requires paths for regular files to be formatted differently from paths for directories, the path shall be treated as a directory path if its last element is a directory-separator, otherwise it shall be treated as a path to a regular file.

[SG note: P0430R1 (for US 75/CA 4) adds support for explicitly specifying the format to use, at least in the constructor.]

Change [path.construct]:

path(const path& p);
path(path&& p) noexcept;

Effects: Constructs an object of class path with pathstring having the original value of p.pathstring. In the second form, p is left in a valid but unspecified state.

path(string_type&& source);

Effects: Constructs an object of class path with pathstring having the original value of source . source is left in a valid but unspecified state.

template <class Source>
path(const Source& source);
template <class InputIterator>
path(InputIterator first, InputIterator last);

Effects:   Constructs an object of class path, storing the effective range of source (27.10.8.3) or the range [first, last) in pathstring, converting format and encoding if required (27.10.8.2).

template <class Source>
path(const Source& source, const locale& loc);
template <class InputIterator>
path(InputIterator first, InputIterator last, const locale& loc);

Requires: The value type of Source and InputIterator is char.

 Effects:  Constructs an object of class path, storing the effective range of source or the range [first, last) in pathstring, after converting format if required and after converting the encoding as follows:

— If value_type is wchar_t, converts to the native wide encoding (27.10.4.10) using the codecvt<wchar_t, char, mbstate_t> facet of loc.

 — Otherwise a conversion is performed using the codecvt<wchar_t, char, mbstate_t> facet of loc, and then a second conversion to the current narrow encoding.

In the example after [path.fmt.cvt] ¶ 7.2, change:

For POSIX-based operating systems, the path is constructed by first using latin1_facet to convert ISO/IEC 8859-1 encoded latin1_string to a wide character string in the native wide encoding (27.10.4.10). The resulting wide string is then converted to a narrow character pathstring string in the current native narrow encoding. If the native wide encoding is UTF-16 or UTF-32, and the current native narrow encoding is UTF-8, all of the characters in the ISO/IEC 8859-1 character set will be converted to their Unicode representation, but for other native narrow encodings some characters may have no representation.

For Windows-based operating systems, the path is constructed by using latin1_facet to convert ISO/IEC 8859-1 encoded latin1_string to a UTF-16 encoded wide character pathstring string. All of the characters in the ISO/IEC 8859-1 character set will be converted to their Unicode representation.

Change [path.assign]:

path& operator=(const path& p);

Effects: If *this and p are the same object, has no effect. Otherwise, modifies pathstring to have the original value of p.pathstring.

Returns: *this.

path& operator=(path&& p) noexcept;

Effects: If *this and p are the same object, has no effect. Otherwise, modifies pathstring to have the original value of p.pathstring. p is left in a valid but unspecified state. [ Note: A valid implementation is swap(p). —end note ]

Returns: *this.

path& operator=(string_type&& source);
path& assign(string_type&& source);

Effects: Modifies pathstring to have the original value of source. source is left in a valid but unspecified state.

Returns: *this.

template <class Source>
path& operator=(const Source& source);
template <class Source>
path& assign(const Source& source);
template <class InputIterator>
path& assign(InputIterator first, InputIterator last);

Effects: Stores the effective range of source (27.10.8.3) or the range [first, last) in pathstring, converting format and encoding if required (27.10.8.2).

Returns: *this.

Change [path.modifiers]:

path& make_preferred();

Effects: Each directory-separator is converted to preferred-separator.

Change [path.modifiers]:

path& replace_extension(const path& replacement = path());

Effects: pathstring (the stored path) is modified as follows:

— Any existing extension()(27.10.8.4.9) is removed from the stored path, then

— If replacement is not empty and does not begin with a dot character, a dot character is appended to the stored path, then

— replacement is concatenated to the stored path.

Returns *this.

Change [path.modifiers]:

void swap(path& rhs) noexcept;

Effects: Swaps the contents of the two paths pathstring and rhs.pathstring.

Change [path.native.obs]:

const string_type& native() const noexcept;

Returns: pathstring.

const value_type* c_str() const noexcept;

Returns: pathstring.c_str().

operator string_type() const;

Returns: pathstring.

[ Note: Conversion to string_type is provided so that an object of class path can be given as an argument to existing standard library file stream constructors and open functions. —end note ]

template <class EcharT, class traits = char_traits<EcharT>,
          class Allocator = allocator<EcharT>>
  basic_string<EcharT, traits, Allocator>
    string(const Allocator& a = Allocator()) const;

Returns: pathstring.

Remarks: All memory allocation, including for the return value, shall be performed by a. Conversion, if any, is specified by 27.10.8.2.

Change [path.generic.obs]:

template <class EcharT, class traits = char_traits<EcharT>,
          class Allocator = allocator<EcharT>>
  basic_string<EcharT, traits, Allocator>
    generic_string(const Allocator& a = Allocator()) const;

Returns: pathstring, reformatted according to the generic pathname format (27.10.8.1).

Remarks: All memory allocation, including for the return value, shall be performed by a. Conversion, if any, is specified by 27.10.8.2.

std::string generic_string() const;
std::wstring generic_wstring() const;
std::string generic_u8string() const;
std::u16string generic_u16string() const;
std::u32string generic_u32string() const;

Returns: pathstring, reformatted according to the generic pathname format (27.10.8.1).

Remarks: Conversion, if any, is specified by 27.10.8.2. The encoding of the string returned by generic_u8string() is always UTF-8.

Change [path.decompose]:

path root_name() const;

Returns: root-name, if pathstring includes root-name, otherwise path().

path root_directory() const;

Returns: root-directory, if pathstring includes root-directory, otherwise path().

...

path relative_path() const;

Returns: A path composed from pathstring, if !empty(), beginning with the first filename after root-path. Otherwise, path().

...

path filename() const;

Returns: empty() ? path() : *--end().

[ Example:

std::cout << path("/foo/bar.txt").filename(); // outputs  "bar.txt"


std::cout << path("/").filename();            // outputs  "/"

std::cout << path(".").filename();            // outputs  "."
std::cout << path("..").filename();           // outputs  ".."

—end example ]

path stem() const;

Note: This change also resolves US 61, Leading dots in filename() should not begin an extension, as approved by LEWG in Issaquah, and affirmed by LWG telecon, and reviewed in Kona.

Returns: if filename() contains a period but does not consist solely of one or two periods, returns the substring of filename() starting at its beginning and ending with the character before the last period. Otherwise, returns filename().

"other than a leading period" was inserted to reflect LEWG guidance from Issaquah that a filename like ".profile" is not to be treated as an extension.

[ Example:

std::cout << path("/foo/bar.txt").stem(); // outputs "bar"
path p = "foo.bar.baz.tar";
for (; !p.extension().empty(); p = p.stem())
std::cout << p.extension() << ’\n’;
// outputs: .tar
// .baz
// .bar

—end example ]

path extension() const;

Note: This change also resolves US 61, Leading dots in filename() should not begin an extension, as approved by LEWG in Issaquah, and affirmed by LWG telecon.

Returns: if filename() contains a period but does not consist solely of one or two periods, returns the substring of filename() starting at the rightmost period and for the remainder of the path. Otherwise, returns an empty path object.

Remarks: Implementations are permitted to define additional behavior for file systems which append additional elements to extensions, such as alternate data streams or partitioned dataset names.

[ Example:

std::cout << path("/foo/bar.txt").extension(); // outputs ".txt"

—end example ]

[ Note: The period is included in the return value so that it is possible to distinguish between no extension and an empty extension. Also note that for a path p, p.stem()+p.extension() == p.filename(). —end note ]

Change [path.query]:

bool empty() const noexcept;

Returns: pathstring.empty().

...

bool is_absolute() const;

Returns: true if pathstring contains an absolute path (27.10.4.1), else false.

[ Example: path("/").is_absolute() is true for POSIX-based operating systems, and false for Windows-based operating systems. —end example ]

Change [path.itr]:

Path iterators iterate over the elements of pathstring in the generic format (27.10.8.1).

A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (24.2.6) except that, for dereferenceable iterators a and b of type path::iterator with a == b, there is no requirement that *a and *b are bound to the same object. Its value_type is path.

Calling any non-const member function of a path object invalidates all iterators referring to elements of that object.

For the elements of pathstring in the generic format, the forward traversal order is as follows:

...

Change [fs.op.canonical]:

path canonical(const path& p, error_code& ec);
path canonical(const path& p, const path& base, error_code& ec);

Effects: Converts p, which must exist, to an absolute path that has no symbolic link, ".", or ".." elements.

...

Change [fs.op.current_path]:

path current_path();
path current_path(error_code& ec);

Returns: The absolute path of the current working directory, obtained  as if by POSIX getcwd(). The signature with argument ec returns path() if an error occurs.

...

Rationale:

The lexical operation specifications leave some room for variation among implementations, but not as much as may be required for native formats; further relaxation would compromise the utility of the operations for portable, predictable path manipulation. Instead, we specify a usable but flexible mapping between the two formats and define each operation in terms of one (or, occasionally, both).

The second bullet item in the first note in [path.fmt.cvt], which says for POSIX- or Windows-based operating systems "There is no need to distinguish between native format and generic format in function arguments.", may not be true on Windows even if the other two bullet items are true.

US 75, CA 4; 27.10.8.4.1 [path.construct]: Extra flag in path constructors is needed
Status: Accept with modifications ✓

Resolved by P0430R2 Section US-75/CA-4.

US 76, CA 5; 27.10.8.1 [path.generic]: root-name definition is over-specified
Status: Accept with modifications ✓

Resolved by P0430R2 Section US-76/CA-5.

US 77, CA 6; 27.10.8.4.3 [path.append]: operator/ and other appends not useful if arg has root-name
Status: Accept with modifications

Discussion:

Passing a path that includes a root path (name or directory) to path.operator/=() simply incorporates the root path into the middle of the result, changing its meaning drastically. LWG 2664 proposes disallowing a path with a root name (but leaves the root directory possibility untouched); US 77/CA 6 (via P0430R0) objects and suggests instead making the same case implementation-defined. (P0430R1 drops the matter in favor of this issue.)

We can carefully define operator/=() to be broadly applicable instead of restricting it. (path::parent_path() and path::lexically_relative() are casualties that must be rewritten; they need fixing anyway for US 58 and Late 16--18 respectively.)

With the better operator/=(), absolute(p,base) is of very little value: the user can easily write absolute(base)/p (or simply base/p if preferable). Since Table 126 produces nonsense in some cases (see Late 24), it is good to remove this complexity. canonical() loses its base argument since it simply forwards it to absolute().

Finally, absolute(p), which would simply be current_path()/p, is of very limited utility on platforms like Windows with complicated notions of current directory. As such, its semantics may be replaced entirely by those of system_complete() (as amended by Billy's email of 8 Feb 2017 04:33:59), which can then be removed (resolving Late 44 and 45). On POSIX, it would remain a simple convenience for current_path()/p with superior portability.

Proposed wording:

Change [path.append]:

path& operator/=(const path& p);

Requires: !p.has_root_name().

Effects:

 Appends path::preferred_separator to pathstring unless:

— an added directory-separator would be redundant, or

— an added directory-separator would change a relative path into an absolute path [Note: An empty path is relative.—end note ] , or

— p.empty() is true, or

— *p.native().cbegin() is a directory-separator.

Then appends p.native() to  pathstring.

Returns: *this.

Change [path.decompose]:

path parent_path() const;

Returns: (empty() || begin() == --end()) ? path() : pp, where pp is constructed as if by starting with an empty path and successively applying operator/= for each element in the range [begin(), --end()).

Change [path.gen]:

path lexically_normal() const;

Returns: *this in normal form ([fs.def.normal.form]).

[ Example:
    assert(path("foo/./bar/..").lexically_normal() == "foo");
    assert(path("foo/.///bar/../").lexically_normal() == "foo/.");

The above assertions will succeed. The second example ends with a current directory (dot) element appended to support operating systems that use different syntax for directory names and regular file names.

On Windows, the returned path’s directory-separator characters will be backslashes rather than slashes, but that does not affect path equality. —end example ]

path lexically_relative(const path& base) const;

Returns: *this made relative to base. Does not resolve (27.10.4.18) symlinks. Does not first normalize (27.10.4.12) *this or base.

Effects: Determines the first mismatched element of *this and base as if by:

auto [a, b] = mismatch(begin(), end(), base.begin(), base.end());

Then,

— if a == begin() and b == base.begin(), returns path(); otherwise

— if a == end() and b == base.end(), returns path("."); otherwise

— returns an object of class path that is default-constructed, followed by

— application of operator/=(path("..")) for each element in [b, base.end()) , and then
— application of operator/= for each element in [a, end()).

[ Example:

assert(path("/a/d").lexically_relative("/a/b/c") == "../../d");
assert(path("/a/b/c").lexically_relative("/a/d") == "../b/c");
assert(path("a/b/c").lexically_relative("a") == "b/c");
assert(path("a/b/c").lexically_relative("a/b/c/x/y") == "../..");
assert(path("a/b/c").lexically_relative("a/b/c") == ".");
assert(path("a/b").lexically_relative("c/d") == "");

The above assertions will succeed. On Windows, the returned path’s directory-separator characters will be backslashes rather than forward slashes, but that does not affect path equality.

 —end example ]

[ Note: If symlink following semantics are desired, use the operational function relative(). —end note ]

[ Note: If normalization (27.10.4.12) is needed to ensure consistent matching of elements, apply lexically_normal() to *this, base, or both. —end note ]

US 78, CA 7; 27.10.15.1 [fs.op.absolute]: Member absolute() in 27.10.4.1 is overspecified for non-POSIX-like O/S
Status: Accept with modifications

Change [fs.op.absolute] and update the synopsis in [fs.filesystem.syn] accordingly:

path absolute(const path& p, const path& base = current_path());

Returns: An absolute path (27.10.4.1) composed according to Table 126.

Table 126 — absolute(const path&, const path&) return value
...

[ Note: For the returned path, rp, rp.is_absolute() is true . —end note ]

Throws: As specified in 27.10.7.

Remove [fs.op.system_complete] and remove system_complete() from the synopsis in [fs.filesystem.syn].

Rationale:

The simple lexical definition produces identical results for path("/foo")/"bar" and path("/foo")/"/bar" and is likely to produce confusion; making it UB does not help that. The "alternative interpretation" from LWG 2664 is the natural extension of the obvious lexical meaning to cases involving a root path on the right (and breaks the symmetry when both paths are absolute), but there was never any proposed replacement more specific than "implementation-defined". This resolution provides the natural meaning and supports non-POSIX root-names as well.

US 79, CA 8; Several: Some operation functions are overspecified for implementation-defined file types
Status: Accept with modifications ✓

Resolved by P0430R2 Section US-79/CA-8.

NB comments submitted as editorial

There was concern that some of these might involve substantive changes, so the SG processed them as ordinary technical comments.

US 38; 27.10.4.13 [fs.def.symlink]:  Duplicates §17.3.16
Status: Accept ✓

WP has been changed.

US 39; 27.10.4.15 [fs.def.parent]: Remove note: Dot and dot-dot are not directories
Status: Accept ✓

WP has been changed.

US 41; 27.10.4.16 [fs.def.parent.other]: The term “parent directory” for a (non-directory) file is unusual
Status: Reject ✓

Insufficient motivation for change. "parent directory" is the term we use to describe the containing directory; we're (already) following POSIX there, even though the POSIX definition is a bit weird.

US 42; 27.10.4.21 [fs.def.symlink]: Pathname resolution does not always resolve a symlink
Status: Reject ✓

There is an apparent corner case contradiction between the POSIX definition and other places in the POSIX standard. The [fs.def.symlink] definition is identical to the POSIX 3.381 Symbolic Link definition () and the SG prefers to keep it that way.

US 47; 27.10.8.1 [path.generic]: “.” and “..” already match the name production
Status: Accept with modifications ✓

 The filesystem small group believes this is not editorial.

Discussion: dot and dot-dot are unneeded as grammar productions, since 'name' already matches them. They also cause ambiguity in the filename grammar. They do, however, need to be defined terms in [fs.def.filename]

Change [fs.def.filename]:

filename
The name of a file. Filenames dot and dot-dot have special meaning. The following characteristics of filenames are operating system dependent:
— The permitted characters. [ Example: Some operating systems prohibit the ASCII control characters (0x00 – 0x1F) in filenames. —end example ]
— The maximum permitted length.
— Filenames that are not permitted.
— Filenames that have special meaning.
— Case awareness and sensitivity during path resolution.
— Special rules that may apply to file types other than regular files, such as directories.

Change [path.generic]:

filename:

name
dot
dot-dot

name:

A sequence of characters other than directory-separator characters. [ Note: Operating systems often place restrictions on the characters that may be used in a filename. For wide portability, users may wish to limit filename characters to the POSIX Portable Filename Character Set: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 . _ - —end note ]

dot:

The filename consisting solely of a single period character (.).

dot-dot:

The filename consisting solely of two period characters (..).

...

The filename dot is treated as a reference to the current directory. The filename dot-dot is treated as a reference to the parent directory. What the filename dot-dot refers to relative to root-directory is implementation-defined. Specific filenames may have special meanings for a particular operating system.

US 50;  27.10.8.3 [path.req]: path requirements ¶ 1.4 largely redundant with ¶ 1.3
Status: Reject ✓

Beman Dawes to open an issue to expose this concern to additional experts. This is not a priority issue for shipping C++17.

Late comments from P0489R0

Quoting P0489R0, "These comments were not submitted in time to be registered as National Body Comments, but should be considered as possible issues against SC 22, N3151, ISO/IEC CD 14882."

Late 15; 27.10.8.4.11 ¶3.1: A “mismatched element” cannot be equal to an iterator

Late 16; 27.10.8.4.11 ¶3.3.1: lexically_relative("..\\foo") produces nonsense.

Late 17; 27.10.8.4.11 ¶3.3.2: Behavior not always appropriate

Late 18; 27.10.8.4.11 ¶4: Behavior wrong in case corresponding to comment Late17

Late 19; 27.10.8.5 ¶2: It is surprising that a path is a container of paths

Recommend NAD. See US 55, US 59.

Late 20; 27.10.11 ¶1: Anemic status structure

Late 21; 27.10.12: directory_entry is just a trivial wrapper for path

Subsumed by LWG 2663 and 2677

Late 22; 27.10.13 ¶6: directory_iterator cumbersome to assemble full path with iterator’s directory

Late 23; 27.10.14.1 ¶28: disable_recursion_pending() name is ugly implementation detail

Late 24; 27.10.15.1 ¶1: absolute() can produce nonsense result

Late 25; 27.10.15.4 ¶4.2: What attributes does copy_file() copy?

Late 26; 27.10.15.6 ¶5: create_directories() complexity assumes syscalls take constant time

Late 27; 27.10.15.7 ¶5: create_directory() specification prevents sensible security measures

Late 28; 27.10.15.10: create_symlink() might misbehave if to is a directory

Late 29; 27.10.15.13: Access to file ID is superior to equivalent()

Suggest proposing a new function, post-C++17, along the lines of file_identity identity(const path&,bool resolve=true);

Late 30; 27.10.15.13 ¶3: equivalent()'s s1==s2 check is ill-formed and could race

Late 31; 27.10.15.13 ¶5: Surprising that equivalent()'s error_code overload can throw

Late 32; 27.10.15.13 ¶5 : equivalent() should not reject special files outright

Late 33; 27.10.15.21: is_other() result surprising

Late 34; 27.10.15.25 ¶5: Could last_write_time() guarantee the error direction

Recommend submitting a paper that researches whether this is in fact possible. If it is possible, providing proposed wording would be helpful.

Late 35; 27.10.15.26: Why is there no way to read permissions?

Recommend NAD. They are available in file_status. If anyone thinks a separate function would be useful, they should submit an issue or a paper.

Late 36; 27.10.15.26: The permissions() error_code overload should be noexcept
Status: Accept ✓

The proposed resolution has been integrated into Late-37 below because it is much easier to understand when full context is provided and having two separate resolutions revising the same wording would be a recipe for disaster.

Late 37; 27.10.15.26 ¶2:permissions() actions should be separate parameter
Status: Accept with modifications ✓

This problem, with the same suggested fix, was also reported for the Filesystem TS. It was not resolved in the TS due to an administrative snafu.

Change [fs.filesystem.syn]:

// 27.10.10, enumerations
enum class file_type;
enum class perms;

enum class copy_options;
enum class directory_options;

...

void permissions(const path& p, perms prms);
void permissions(const path& p, perms prms, error_code& ec) ;

Strike the following rows in [fs.enum] Table nnn — Enum class perms:

• add_perms
• remove_perms
• symlink_nofollow

Insert a new sub-section after [enum.perms]:

Enum class perm_options [enum.perm_options]

Name	Meaning
replace	permissions shall replace the file's permission bits with perm.
add	permissions shall replace the file's permission bits with the bitwise OR of perm and the file’s current permission bits.
remove	permissions shall replace the file's permission bits with the bitwise AND of the complement of perm and the file’s current permission bits.
nofollow	permissions shall change the permissions of a symbolic link itself rather than the permissions of the file the link resolves to.

Change [fs.op.permissions]:

void permissions(const path& p, perms prms);
void permissions(const path& p, perms prms, error_code& ec) ;

Requires: !((prms & perms::add_perms) != perms::none && (prms & perms::remove_perms) != perms::none).

Effects: Applies the effective permissions bits from prms to the file p resolves to, or if that file is a symbolic link and symlink_nofollow is not set in prms, the file that it points to, as if by POSIX fchmodat(). The effective permission bits are determined as specified in Table 127, where s is the result of (prms & perms::symlink_nofollow) != perms::none ? symlink_status(p) : status(p).

[ Note: Conceptually permissions are viewed as bits, but the actual implementation may use some other mechanism. —end note ]

Throws: As specified in 27.10.7.