Doc. no.	N4005
Date:	2014-05-24
Project:	Programming Language C++
Reply to:	Beman Dawes <bdawes at acm dot org>

File System TS Defect Report List (Revision R1)

Revised 2014-05-24 at 12:05:47 UTC

Reference ISO/IEC TS 18822

Also see:

Table of Contents for all SG3 issues.
Index by Section for all SG3 issues.
Index by Status for all SG3 issues.
Active Issues List
Closed Issues List

This document contains only SG3 issues which have been closed by the File System Study Group (SG3) after being found to be defects in the standard. That is, issues which have a status of DR, TC1, C++11, or Resolved. See the Closed Issues List for issues closed as non-defects. See the Active Issues List for active issues and more information. The introductory material in that document also applies to this document.

Revision History

R1: 2014-05-23 SG-3 File System TS
- Summary:
  - 27 open issues, up by 27.
  - 35 closed issues, up by 35.
  - 62 issues total, up by 62.
- Details:
  - Added the following 3 Review issues: 25, 27, 57.
  - Added the following 19 New issues: 34, 35, 36, 37, 38, 40, 41, 42, 45, 48, 49, 54, 56, 58, 59, 60, 61, 62, 63.
  - Added the following 5 Open issues: 4, 5, 11, 22, 53.
  - Added the following NAD Future issue: 12.
  - Added the following 22 WP issues: 1, 2, 3, 6, 7, 8, 9, 14, 15, 16, 18, 19, 21, 24, 29, 32, 33, 44, 47, 50, 52, 55.
  - Added the following NAD Editorial issue: 39.
  - Added the following 9 NAD issues: 10, 13, 17, 23, 26, 28, 30, 31, 46.
  - Added the following 2 Dup issues: 43, 51.
  - No issues changed.

Defect Reports

1. [PDTS] Make namespaces consistent with Library TS policy

Section: X All Status: WP Submitter: FI-5, US-5, GB-3, CH-6 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

The PDTS used a placeholder namespace "tbs" since the Standard Library policy for TS namespaces had not yet been fully articulated.

[2014-02-11 Issaquah: Project editor to make indicated changes to WP, post notice on lib and SG3 reflectors.]

Proposed resolution:

[2014-02-07: Beman Dawes]

Throughout the WP, change namespace "tbs" to "experimental" as described in the Library Fundamentals TS working paper, 1.3 Namespaces and headers [general.namespaces].

2. [PDTS] Tighten specification when there is no reasonable behavior

Section: X 2.1 [fs.conform.9945] Status: WP Submitter: FI-1 Opened: 2014-01-20 Last modified: 2014-04-18

View all other issues in 2.1 [fs.conform.9945].

View all issues with WP status.

Discussion:

It is unfortunate that error reporting for inability to provide reasonable behaviour is completely implementation-defined. This hurts portability in the sense that programmers have no idea how errors will be reported and cannot anticipate anything.

Change "If an implementation cannot provide any reasonable behavior, the implementation shall report an error in an implementation-defined manner." to "If an implementation cannot provide any reasonable behavior, the code using the facilities for which reasonable behaviour cannot be provided shall be ill-formed." and strike the note.

[2014-02-07, Beman Dawes suggests wording]

[2014-02-12, Daniel Kr�gler comments:]

In our code bases we routinely have to target different filesystems, notably POSIX-based and Windows. While on Windows there is no meaning in setting the owner_exec permission, for example, this is required on POSIX systems when the corresponding file should be executable. Still, attempting to invoke this operation should be possible. It would be OK, if we got a defined runtime response to this, such as a specifically defined error code value that could be tested either via the error_code& overload, but it would be IMO unacceptable for end-users to tell them "Well, this code may not compile". I don't think that we can teach people that code written using the filesystem operations might or might not compile. It would be very valuable to have at least a clear indication that implementers are required to give a defined runtime-response if they do believe that this operation cannot be implemented resulting in "reasonable behaviour".

[2014-02-12, Proposed wording updated to reflect LWG/SG-3 discussion in Issaquah.

Since the standardese to carry out the LWG/SG-3 "throw or error code" intent is best achieved by reference to the Error reporting section, a note was added by the project editor. Please review carefully. ]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 2.1:

If an implementation cannot provide any reasonable behavior, the implementation shall report an error ~~in an implementation-defined manner~~ as specified in § 7 [fs.err.report]. [Note: This allows users to rely on an exception being thrown or an error code being set when an implementation cannot provide any reasonable behavior. — end note] .

3. [PDTS] Filename length needs bullet item

Section: X 4.7 [fs.def.filename] Status: WP Submitter: CH-2 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Filename lengths are also implementation dependent. This is not the same as FILENAME_MAX that specifies the maximum length of pathnames.

Add a bullet: "Length of filenames."

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

Change 4.7 [fs.def.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.

6. [PDTS] Path depth is underspecified

Section: X 4.15 [fs.def.path] Status: WP Submitter: CH-5 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

Path depth is implementation dependent.

Add a paragraph: "The maximum length of the sequence (i.e. the maximum depth) is implementation dependent.

[2014-02-07, Beman Dawes comments]

"implementaton defined" and "operating system dependent" are well defined terms in this TS, but "implementation dependent" is not well defined. The path depth is operating system dependent, so that's the form used in the proposed wording.

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

Change 4.15 [fs.def.path]:

4.15 path [fs.def.path]

A sequence of elements that identify the location of a file within a filesystem. The elements are the root-name_opt , root-directory_opt , and an optional sequence of filenames.

The maximum number of elements in the sequence is operating system dependent.

7. [PDTS] Unhelpful comment for `struct space_info`

Section: X 6 [fs.filesystem.synopsis], 15.32 [fs.op.space] Status: WP Submitter: GB-4 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

Use of the term a 'non-privileged' process. The comment for available in the struct space_info refers to: free space available to a non-privileged process. This seems quite specific to a POSIX implementation (on Windows, for instance, the equivalent data would be user-specific but not directly related to privilege)

Remove the comment and add a note to 15.32 [fs.op.space]: [Note: the precise meaning of available space is implementation dependent. — end note]

[2014-02-07, Beman Dawes comments]

"implementaton defined" and "operating system dependent" are well defined terms in this TS, but "implementation dependent" is not well defined. The meaning of available is operating system dependent, so that's the form used in the proposed wording.

[2014-02-07, Beman Dawes provides wording]

Proposed resolution:

Change 6 [fs.filesystem.synopsis]:

uintmax_t available; // free space available to a non-privileged process
Add Remarks to 15.32 [fs.op.space]:

Remarks: The value of member space_info::available is operating system dependent. [Note: available may be less than free. — end note]

8. [PDTS] `file_time_type` underspecified

Section: X [fs.filesystem.synopsis] Status: WP Submitter: CH-7 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Must the file_time_type hold times before 1960 and after 2050?

Specify the requirements to unspecified-trivial-clock for file_time_type.

[2014-02-10, Daniel suggests wording]

[ 2014-02-11 Issaquah: (1)Implementation-defined. See wiki notes for rationale. (2) Leave other additions in place, but insert "the" before "resolution" (3) Strike "unspecified-" from "unspecified-trivial-type" in two places. Beman to provide wording for review next meeting. ]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Modify 6 [fs.filesystem.synopsis] as indicated:
```
    typedef chrono::time_point<unspecified-trivial-clock>  file_time_type;
  
```
~~unspecified-~~trivial-clock is an ~~unspecified type provided by the implementation~~ implementation-defined type that satisfies the TrivialClock requirements (~~C++11~~ISO 14882:2011 §20.12.3) and that is capable of representing and measuring file time values. Implementations should ensure that the resolution and range of file_time_type reflect the operating system dependent resolution and range of file time values.

9. [PDTS] Unclear why range-based-for functions return different types

Section: X 6 [fs.filesystem.synopsis] Status: WP Submitter: FI-2 Opened: 2014-01-20 Last modified: 2014-04-08

View other active issues in 6 [fs.filesystem.synopsis].

View all other issues in 6 [fs.filesystem.synopsis].

View all issues with WP status.

Discussion:

It is unclear why the range-for support functions (begin()/end()) for directory_iterator and recursive_directory_iterator return different types for begin() and end(), namely that begin() returns a reference to const and end() returns a value.

[2014-02-07: Beman Dawes provides comments from the Boost implementation:]

  //  begin() and end() are only used by a range-based for statement in the context of
  //  auto - thus the top-level const is stripped - so returning const is harmless and
  //  emphasizes begin() is just a pass through.

[2014-02-08: Daniel responds to Beman]

The difference in return types becomes relevant, when testing whether e.g. directory_iterator would satisfy the Traversable requirements as currently specified in N3763. Expressed in code form these requirements impose that the following assertion holds:

  static_assert(std::is_same<
      decltype(std::range_begin(std::declval<directory_iterator>())),
      decltype(std::range_end(std::declval<directory_iterator>()))
    >::value, "No Traversable type");

Both directory_iterator and recursive_directory_iterator won't satisfy this requirement currently.

[ 2014-02-11 Issaquah: Change begin() argument and return to pass-by-value. See wiki notes for rationale. Beman to provide wording for review next meeting. ]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 6 [fs.filesystem.synopsis]:

  class directory_iterator;

  // enable directory_iterator range-based for statements
  const directory_iterator& begin(const directory_iterator& iter) noexcept;
  directory_iterator end(const directory_iterator&) noexcept;

  class recursive_directory_iterator;

  // enable recursive_directory_iterator range-based for statements
  const recursive_directory_iterator& begin(const recursive_directory_iterator& iter) noexcept;
  recursive_directory_iterator end(const recursive_directory_iterator&) noexcept;

Change 13.2 [directory_iterator.nonmembers]:

These functions enable use of directory_iterator with C++11 range-based for statements.
```
const directory_iterator& begin(constdirectory_iterator& iter) noexcept;
```
Returns: iter.
```
directory_iterator end(const directory_iterator&) noexcept;
```
Returns: directory_iterator().
Change 14.2 [rec.dir.itr.nonmembers]:

These functions enable use of recursive_directory_iterator with C++11 range-based for statements.
```
const recursive_directory_iterator& begin(constrecursive_directory_iterator& iter) noexcept;
```
Returns: iter.
```
recursive_directory_iterator end(const recursive_directory_iterator&) noexcept;
```
Returns: recursive_directory_iterator().

14. [PDTS] Incorrect postconditions for `path` copy/move constructor

Section: X 8.4.1 [path.construct] Status: WP Submitter: GB-7, CH-10 Opened: 2014-01-20 Last modified: 2014-04-08

View all other issues in 8.4.1 [path.construct].

View all issues with WP status.

Discussion:

The postconditions for the copy/move constructor for path are shown as "empty()". This appears to have been incorrectly copied from the default ctor.

Remove the 'postconditions' clause from the copy/move ctor.

[2014-02-07, Beman Dawes suggests wording]

Proposed resolution:

Change 8.4.1 [path.construct]:

      path(const path& p);
      path(path&& p) noexcept;
    
Effects: Constructs an object of class path with pathname having the original value of p.pathname. In the second form, p is left in a valid but unspecified state.

Postconditions: empty().

15. [PDTS] Missing behavior for characters with no representation

Section: X 8.2.2 [path.type.cvt], X 8.4.1 [path.construct] Status: WP Submitter: GB-8 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

No specification for characters with no representation. The example at the end of 8.4.1 refers to "for other native narrow encodings some characters may have no representation" - what happens in such cases?

Suggested action:

Add some definition of the behaviour for characters with no representation.

[2014-02-12 Applied LWG/SG-3 Issaquah wording tweaks to make characters referred to plural.]

[2014-02-08, Beman Dawes provides wording]

Proposed resolution:

Add a paragraph at the end of 8.2.2 [path.type.cvt]:

If the encoding being converted to has no representation for source characters, the resulting converted characters, if any, are unspecified.

16. [PDTS] Append behavior underspecified if target is empty

Section: X 8.4.3 [path.append] Status: WP Submitter: CH-11 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Is the added separator redundant in p1 /= p2, where p1 is empty? I.e. does the result start with a separator?

Suggested action:

Specify what behaviour is required.

[2014-02-07: Beman Dawes comments]

The second bullet item is supposed to deal with the empty() condition.

[2014-02-12 LWG/SG-3 Issaquah: The text is correct as written, however adding a note will clarify this and address the NB comment.]

Proposed resolution:

Change 8.4.3 [path.append]:

Effects:

Appends path::preferred_separator to pathname unless:

an added separator would be redundant, or

would change an relative path to an absolute path [Note: An empty path is relative. — end note], or

p.empty(), or

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

Then appends p.native() to pathname.

18. [PDTS] `is_absolute()` return clause confusing

Section: X 8.4.10 [path.query] Status: WP Submitter: FI-7 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with WP status.

Discussion:

is_absolute says: "Returns: true if the elements of root_path() uniquely identify a file system location, else false." The "uniquely identify a location" seems confusing in presence of symlinks.

Suggested action:

Clarify the returns clause so that there's no confusion about symlinks and 'location'.

[2014-02-10 Beman Dawes provides wording]

Proposed resolution:

Change 8.4.10 path query [path.query]:

bool is_absolute() const;
Returns: true if ~~the elements of root_path() uniquely identify a file system location~~ pathname contains an absolute path (4.1 [fs.def.absolute-path]) , else false.

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

19. [PDTS] Consider using quoted manipulators

Section: X 8.6.1 [path.io] Status: WP Submitter: FI-8 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

"[Note: Pathnames containing spaces require special handling by the user to avoid truncation when read by the extractor. — end note]" sounds like a quoted manipulator as specified in the C++14 draft in [quoted.manip] would be useful.

Consider using quoted manipulators for stream insertion and extraction.

[2014-02-10, Daniel suggests wording]

[2014-02-12 Applied LWG/SG-3 Issaquah wording tweak to use ISO doc number for reference to C++14.]

Proposed resolution:

Change 8.6.1 [path.io] as indicated:
```
template <class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& os, const path& p);
```
Effects: os << quoted(p.string<charT, traits>()).
~~[Note: Pathnames containing spaces require special handling by the user to avoid truncation when read by the extractor. — end note]~~
[Note: The quoted function is described in ISO 14882:2014 �27.7.6. — end note]
Returns: os
```
template <class charT, class traits>
basic_istream<charT, traits>&
operator>>(basic_istream<charT, traits>& is, path& p);
```
Effects:
```
basic_string<charT, traits> tmp;
is >> quoted(tmp);
p = tmp;
```

21. [PDTS] `directory_entry operator==` needs clarification

Section: X 12.3 [directory_entry.obs] Status: WP Submitter: GB-12 Opened: 2014-01-20 Last modified: 2014-04-18

View all other issues in 12.3 [directory_entry.obs].

View all issues with WP status.

Discussion:

Since operator== for directory_entry does not check status, it would be worth highlighting that operator== only checks that the paths match.

Suggested action:

Add: [Note: does not include status values — end note]

[2014-02-09, Beman Dawes suggest wording]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted. Typo /no/not/ fixed per suggestion.]

Proposed resolution:

To 12.3 [directory_entry.obs] operator== add:

[Note: Status members do not participate in determining equality. — end note]

24. [PDTS] Incorrect effects clause for path `copy`

Section: X 15.3 [fs.op.copy] Status: WP Submitter: GB-14 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Incorrect effects clause for path copy — the effect clause for copy [fs.op.copy] includes "equivalent(f, t)" — there is no equivalent() function defined for variables of this type (file_status)

Suggested action:

Replace with "equivalent(from, to)"

[2014-02-09, Beman Dawes suggests wording]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 15.3 [fs.op.copy]:

Report an error as specified in Error reporting if:

!exists(f).

equivalent(f, t from, to).

is_other(f) || is_other(t).

is_directory(f) && is_regular_file(t).

29. [PDTS] Unclear semantics of `read_symlink` on error

Section: X 15.27 [fs.op.read_symlink] Status: WP Submitter: GB-16 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

Unclear semantics of read_symlink on error: 15.27 [fs.op.read_symlink] has: Returns: If p resolves to a symbolic link, a path object containing the contents of that symbolic link. Otherwise path(). and also [Note: It is an error if p does not resolve to a symbolic link. -- end note]

I do not believe path() can be a valid return for the overload not taking error_code.

Strike "Otherwise path()."

[2014-02-09, Beman Dawes provides wording]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 15.27 [fs.op.read_symlink]:

Returns: If p resolves to a symbolic link, a path object containing the contents of that symbolic link. ~~Otherwise path().~~ The signature with argument ec returns path() if an error occurs.

Throws: As specified in Error reporting. [Note: It is an error if p does not resolve to a symbolic link. — end note]

32. [PDTS] `system_complete()` example needs clarification

Section: X 15.36 [fs.op.system_complete] Status: WP Submitter: FI-10 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

"[Example: For POSIX based operating systems, system_complete(p) has the same semantics as complete(p, current_path())." What is this complete that is referred here?

Clarify the example.

[2014-02-10 Beman Dawes suggests wording]

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 15.36 [fs.op.system_complete]:

[Example: For POSIX based operating systems, system_complete(p) has the same semantics as completeabsolute(p, current_path()).

33. [PDTS] `unique_path()` is a security vulnerability

Section: X 15.38 [fs.op.unique_path] Status: WP Submitter: CH-19 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

unique_path() is a security vulnerability. As the Linux manual page for the similar function tmpnam() writes in the "BUGS" section: "Never use this function. Use mkstemp(3) or tmpfile(3) instead." mkstemp() and tmpfile() avoid the inherent race condition of unique_path() by returning an open file descriptor or FILE*.

[Beman Dawes comments: 10 Feb 2014:]

There are two issues here:

Confusion over what unique_path does and how it is used. The function is misleadingly named. These issue have arisen in the past, but apparently not been fully corrected. The suggested fix is to (1) rename the function and (2) provide an example of how to use the function safely with fstreams or even C I/O. See below for proposed wording.

Very real security concerns. See issue 54. The security concerns are probably best dealt with in the next File System TS, since a full-blown proposal is needed and will likely take several years to develop.

[ 2014-02-11 Issaquah: Strike the function. ]

[2014-02-12 The following Proposed resolution from CH-19 was moved here to avoid confusion with the final Proposed resolution wording from the WG/SG3.]

Remove this function. Consider providing a function create_unique_directory(). If it fits the scope of the proposed TS, consider providing functions create_unique_file() that returns ifstream, ofstream and iofstream.

[ 2014-02-12 The following Proposed wording was moved here to avoid confusion with the final Proposed resolution wording from the WG/SG3. ]

[2014-02-10 Beman Dawes]

Previous resolution from Beman [SUPERSEDED]:

Change 15.38 [fs.op.unique_path]:
    path unique_pathgenerate_random_filename(const path& model="%%%%-%%%%-%%%%-%%%%");
    path unique_pathgenerate_random_filename(const path& model, error_code& ec);
  
The unique_path generate_random_filename function generates a name suitable for temporary files, including directories. The name is based on a model that uses the percent sign character to specify replacement by a random hexadecimal digit.

[Note: The more bits of randomness in the generated name, the less likelihood of prior existence or being guessed. Each replacement hexadecimal digit in the model adds four bits of randomness. The default model thus provides 64 bits of randomness. --end note]

Returns: A path identical to model, except that each occurrence of the percent sign character is replaced by a random hexadecimal digit character in the range 0-9, a-f. The signature with argument ec returns path() if an error occurs.

Throws: As specified in Error reporting.

Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. [Note: Such generators may block until sufficient entropy develops. --end note]

Replace this example with one that opens a std::ofstream:
[Example:
        cout << unique_pathgenerate_random_filename("test-%%%%%%%%%%%.txt") << endl;
      
Typical output would be "test-0db7f2bf57a.txt". Because 11 hexadecimal output characters are specified, 44 bits of randomness are supplied. -- end example]

Proposed resolution:

Remove the two unique_path function signatures from 6 [fs.filesystem.synopsis].

Remove 15.38 [fs.op.unique_path] in its entirety.

[This removes all references the function from the working draft.]

44. [PDTS] enum classes `copy_options` and `perms` should be bitmask types

Section: X 10.2 [enum.copy_options], X 10.3 [enum.perms] Status: WP Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

View all other issues in 10.2 [enum.copy_options].

View all issues with WP status.

Discussion:

enum classes copy_options and perms should be bitmask types.

[2014-02-08 Daniel comments and suggests wording]

Since both enum types contain enumeration values that denote the value zero, they are currently not allowed to be described as bitmask types. This issue depends on LWG issue 1450, which — if it would be accepted — would allow for applying this concept to these enumeration types.

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

This wording is relative to SG3 working draft and assumes that LWG 1450 has been resolved.

Change [enum.copy_options] as indicated:

~~This enumeration~~The enum class type copy_options is a bitmask type (C++11 §17.5.2.1.3) that specifies bitmask constants used to control the semantics of copy operations. The constants are specified in option groups. […]
Change [enum.perms] as indicated:

~~This enumeration~~The enum class type perms is a bitmask type (C++11 §17.5.2.1.3) that specifies bitmask constants used to identify file permissions.

47. [PDTS] `last_write_time()` uses ill-formed cast

Section: X 15.25 [fs.op.last_write_time] Status: WP Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

View all other issues in 15.25 [fs.op.last_write_time].

View all issues with WP status.

Discussion:

In last_write_time, static_cast<file_time_type>(-1) is ill formed, (possibly should be chrono<unspecified-trivial-clock>::from_time_t(-1)).

[2014-02-08 Daniel comments and provides wording]

I agree that the current wording needs to be fixed, but it is unclear to me whether invoking from_time_t (which is only guaranteed to exist for std::chrono::system_clock) with a value of time_t(-1) is a well-defined operation. Reason is that the C Standard makes a difference between a calendar time and the value time_t(-1) as an error indication. But the specification of system_clock::from_time_t only says "A time_point object that represents the same point in time as t […]" and it is not clear whether time_t(-1) can be considered as a "point in time". Instead of relying on such a potentially subtle semantics of the conversion result of time_t(-1) to std::chrono::system_clock::time_point with a further conversion to file_time_type (which in theory could led to overflow or underflow and thus another potential source of undefined behaviour), I suggest to change the current error value of last_write_time to one of the well-define limiting values of file_time_type, e.g. file_time_type::min().

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

This wording is relative to SG3 working draft.

Change the last write time prototype specification, 15.25 [fs.op.last_write_time], as indicated:
```
file_time_type last_write_time(const path& p);
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
```
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns static_cast<file_time_type>(-1)file_time_type::min() if an error occurs.

50. [PDTS] `path::compare(const string& s)` wrong argument type

Section: X 8 [class.path] Status: WP Submitter: Stephan T. Lavavej Opened: 2014-02-03 Last modified: 2014-04-18

View all other issues in 8 [class.path].

View all issues with WP status.

Discussion:

path has "int compare(const string& s) const;" but it should almost certainly take const string_type&, since the third overload takes const value_type*.

[2014-02-08 Daniel comments and provides wording]

This issue is the same as 43 and resolves that issue as well.

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

This wording is relative to SG3 working draft.

Change class path synopsis, 8 [class.path], as indicated:

// compare
int compare(const path& p) const noexcept;
int compare(const string_type& s) const;
int compare(const value_type* s) const;

Change path compare prototype specification, 8.4.8 [path.compare], as indicated:
```
int compare(const string_type& s) const;
```

52. [PDTS] Better to avoid deriving from `std::iterator`

Section: X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] Status: WP Submitter: Stephan T. Lavavej Opened: 2014-02-03 Last modified: 2014-04-18

View all other issues in 13 [class.directory_iterator].

View all issues with WP status.

Discussion:

Although the Standard has made this mistake almost a dozen times, I recommend not depicting directory_iterator and recursive_directory_iterator as deriving from std::iterator, since that's a binding requirement on implementations. Instead they should be depicted as having the appropriate typedefs, and leave it up to implementers to decide how to provide them. (The difference is observable to users with is_base_of, not that they should be asking that question.)

[2014-02-08 Daniel comments and provides wording]

This issue is basically similar to the kind of solution that had been used to remove the requirement to derive from unary_function and friends as described by N3198 and I'm strongly in favour to follow that spirit here as well. I'd like to add that basically all "newer" iterator types (such as the regex related iterator don't derive from std::iterator either.

Another reason to change the current specification is the fact that it currently says that the member types pointer and reference would be determined to value_type* and value_type& (that is mutable pointers and references), which conflicts with the specification of the return types of the following members:

const directory_entry& operator*() const;
const directory_entry* operator->() const;

The proposed fording fixes this by correcting these typedef to corresponding const access.

The very same objections had been expressed by issue 51 and the below given wording resolves this issue as well.

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

This wording is relative to SG3 working draft.

Change class directory_iterator synopsis, [class.directory_iterator], as indicated:

namespace std { namespace tbd { namespace filesystem {

      class directory_iterator :
        public iterator<input_iterator_tag, directory_entry>
      {
      public:
        typedef directory_entry        value_type;
        typedef ptrdiff_t              difference_type;
        typedef const directory_entry* pointer;
        typedef const directory_entry& reference;
        typedef input_iterator_tag     iterator_category;

        // member functions
        […]
      };

} } }  // namespaces std::tbd::filesystem

Change class recursive_directory_iterator synopsis, [class.rec.dir.itr], as indicated:

namespace std { namespace tbd { namespace filesystem {

      class recursive_directory_iterator :
        public iterator<input_iterator_tag, directory_entry>
      {
      public:
        typedef directory_entry        value_type;
        typedef ptrdiff_t              difference_type;
        typedef const directory_entry* pointer;
        typedef const directory_entry& reference;
        typedef input_iterator_tag     iterator_category;

        // constructors and destructor
        […]
        
        // modifiers
        recursive_directory_iterator& operator=(const recursive_directory_iterator&) = default;
        recursive_directory_iterator& operator=(recursive_directory_iterator&&) = default;
        
        const directory_entry& operator*() const;
        const directory_entry* operator->() const;

        recursive_directory_iterator& operator++();
        recursive_directory_iterator& increment(error_code& ec);

        […]
      };

} } }  // namespaces std::tbd::filesystem

55. [PDTS] Clarify Error reporting

Section: X 7 [fs.err.report] Status: WP Submitter: Beman Dawes Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with WP status.

Discussion:

The proposed change below was suggested in Issaquah as part of the resolution of issue 13 to clarify the Error reporting section. LWG/SG3 liked the change, but since issue 13 was NAD requested that a separate issue be opened.

[2014-02-13 LWG/SG-3 Issaquah: Proposed wording accepted.]

Proposed resolution:

Change 7 [fs.err.report]:

Functions not having an argument of type error_code& report errors as follows, unless otherwise specified:

When a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, an exception of type filesystem_error shall be thrown. For functions with a single path argument, that argument shall be passed to the filesystem_error constructor with a single path argument. For functions with two path arguments, the first of these arguments shall be passed to the filesystem_error constructor as the path1 argument, and the second shall be passed as the path2 argument. The filesystem_error constructor's error_code argument is set as appropriate for the specific operating system dependent error.

Failure to allocate storage is reported by throwing an exception as described in C++11 § 17.6.4.10.

Destructors throw nothing.

Functions having an argument of type error_code& report errors as follows, unless otherwise specified:

If a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, the error_code& argument is set as appropriate for the specific operating system dependent error. Otherwise, clear() is called on the error_code& argument.

File System TS Defect Report List (Revision R1)

Revision History

Defect Reports

1. [PDTS] Make namespaces consistent with Library TS policy

2. [PDTS] Tighten specification when there is no reasonable behavior

3. [PDTS] Filename length needs bullet item

6. [PDTS] Path depth is underspecified

7. [PDTS] Unhelpful comment for struct space_info

8. [PDTS] file_time_type underspecified

9. [PDTS] Unclear why range-based-for functions return different types

14. [PDTS] Incorrect postconditions for path copy/move constructor

15. [PDTS] Missing behavior for characters with no representation

16. [PDTS] Append behavior underspecified if target is empty

18. [PDTS] is_absolute() return clause confusing

19. [PDTS] Consider using quoted manipulators

21. [PDTS] directory_entry operator== needs clarification

24. [PDTS] Incorrect effects clause for path copy

29. [PDTS] Unclear semantics of read_symlink on error

32. [PDTS] system_complete() example needs clarification

33. [PDTS] unique_path() is a security vulnerability

44. [PDTS] enum classes copy_options and perms should be bitmask types

47. [PDTS] last_write_time() uses ill-formed cast

50. [PDTS] path::compare(const string& s) wrong argument type

52. [PDTS] Better to avoid deriving from std::iterator

55. [PDTS] Clarify Error reporting

7. [PDTS] Unhelpful comment for `struct space_info`

8. [PDTS] `file_time_type` underspecified

14. [PDTS] Incorrect postconditions for `path` copy/move constructor

18. [PDTS] `is_absolute()` return clause confusing

21. [PDTS] `directory_entry operator==` needs clarification

24. [PDTS] Incorrect effects clause for path `copy`

29. [PDTS] Unclear semantics of `read_symlink` on error

32. [PDTS] `system_complete()` example needs clarification

33. [PDTS] `unique_path()` is a security vulnerability

44. [PDTS] enum classes `copy_options` and `perms` should be bitmask types

47. [PDTS] `last_write_time()` uses ill-formed cast

50. [PDTS] `path::compare(const string& s)` wrong argument type

52. [PDTS] Better to avoid deriving from `std::iterator`