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

# File System TS Closed Issues 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
- Defect Reports List

This document contains only SG3 issues which have been closed by the File System Study Group as duplicates or not defects. That is, issues which have a status of Dup or NAD. See the Active Issues List active issues and more information. See the Defect Reports List for issues considered defects. 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.

## Closed Issues

### 10. [PDTS] Apparently inconsistent return types from several functions

Section: X 6 [fs.filesystem.synopsis] Status: NAD Submitter: FI-4 Opened: 2014-01-20 Last modified: 2014-04-18

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

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

View all issues with NAD status.

Discussion:

It is unclear why `copy`, `copy_file` and `copy_symlink` have different return types, and why the attribute-version of `create_directory` has a different return type than the `create_directory` that takes no attributes. The status/error reporting in these functions seems inconsistent.

Resolution:

Make the status/error reporting consistent or add a note explaining why it's different.

[ 2014-02-11 Issaquah: NAD. LWG/SG-3 reviewed each function and return type, and found that since they have different functionality different return types are warranted. `create_directory` has an inconsistent return type between the synopsis and the description. This has subsequently been corrected editorially. ]

Proposed resolution:

### 12. [PDTS] `uintmax_t` too small for large file sizes

Section: X [fs.filesystem.synopsis], [fs.op.file_size] Status: NAD Future Submitter: CH-8 Opened: 2014-01-20 Last modified: 2014-04-18

Discussion:

`uintmax_t` is specified to hold at least 64 bit. This is not enough for sizes beyond 4 [sic] exabytes.

Specify whether an implementation must provide a `uintmax_t` that can hold the maximum possible space and file size values.

[2014-02-06: Jeffery Yasskin points out 64-bits unsigned actually has a maximum value of "16 exabytes, not 4"]

[2014-02-07: Beman Dawes suggests: This should be NAD. Such ultra-large files are the province of enterprise-wide filesystems such as requested by IBM and others for a follow-on SG3 TS. That would be the best vehicle to address this concern IMO.]

[ 2014-02-11 Issaquah: NAD Future. ]

Proposed resolution:

### 13. [PDTS] Missing actual error conditions thrown

Section: X 7 [fs.err.report] etc. Status: NAD Submitter: CH 9 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with NAD status.

Discussion:

The specification of the actual error conditions for the functions that specify Throws: As specified in Error reporting. is missing.

Add those specifications.

[2014-02-07, Beman Dawes comments]

The actual error codes, and thus the error conditions, are determined by the operating system, and thus operating system dependent.

[2014-02-11 Issaquah]

There is no consensus for a change. LWG/SG3 requested a separate issue be opened to clarify 7 [fs.err.report]. See issue 55.

Proposed resolution:

### 17. [PDTS] `path` member `swap()` unnecessary

Section: X 8.4.5 [path.modifiers] Status: NAD Submitter: CH-12 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with NAD status.

Discussion:

As we have move semantics, member `swap` functions shouldn't be necessary any more.

[2014-02-12 LWG/SG-3 Issaquah ]

No consensus for change. STL pointed out that swap should be noexcept and will submit a separate issue.

Proposed resolution:

Remove `swap()`.

### 23. [PDTS] Request for `create_regular_file()` and/or `touch()`

Section: X 15 Status: NAD Submitter: CH-14 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with NAD status.

Discussion:

Since `create_symlink()`, `create_hardlink()`, and `create_directory()` exist, there's no reason not to have a `create_regular_file()` function.

Consider adding a function `create_regular_file()` with the behaviour of the POSIX `touch` command.

[Beman comments]

`create_regular_file()` and `touch()` should be different functions since their behavior would differ if the file already exists; touch() updates the last write date.

I have often wanted `create_regular_file()` but never got around to adding it.

While `touch` is quite useful from the command line, I'm less sure of its usefulness as a library function. It is trivial for a user to implement.

Whether or not it is appropriate to add operational functions this late in the PDTS process is questionable.

[2014-02-13 LWG/SG-3 Issaquah: No consensus for change at this time.]

Proposed resolution:

### 26. [PDTS] Equivalence is a volatile property

Section: X 15.13 [fs.op.equivalent] Status: NAD Submitter: CH-16 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with NAD status.

Discussion:

Equivalence is a volatile property.

Consider adding a note that equivalence cannot be determined race-free.

[2014-02-13 LWG/SG-3 Issaquah: No consensus for change. Section 2.1 description of races is sufficient.]

Proposed resolution:

### 28. [PDTS] Possible `last_write_time()` postcondition?

Section: X 15.25 [fs.op.last_write_time] Status: NAD Submitter: GB-15 Opened: 2014-01-20 Last modified: 2014-04-08

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

View all issues with NAD status.

Discussion:

The constraint on `last_write_time` is too weak: It is noted that the postcondition of `last_write_time(p) == new_time` is not specified since it might not hold for file systems with coarse time granularity.

However, might it be possible to have a postcondition that `last_write_time(p) <= new_time` ?

Add postcondition: `last_write_time(p) <= new_time`

[2014-02-09, Beman Dawes comments:]

That assumes the file system rounds down. We don't know which direction a file system rounds. Nice try, but this one looks NAD to me.

[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]

Proposed resolution:

### 30. [PDTS] `remove()` must avoid race

Section: X 15.28 [fs.op.remove] Status: NAD Submitter: CH-17 Opened: 2014-01-20 Last modified: 2014-04-08

View all issues with NAD status.

Discussion:

The specification can be read to require the existence test. As this introduces a race, the existence test must not happen.

Change to: "Effects: `p` is removed as if by POSIX `remove()`."

[2014-02-13 LWG/SG-3 Issaquah: Insufficient consensus for change. Vote for NAD: 9 0 0 2 1.]

Proposed resolution:

This wording is relative to SG3 working draft.

1. Change X 15.28 [fs.op.remove] as indicated:

   > Effects: If `exists(symlink_status(p,ec))`, it `p` is removed as if by POSIX `remove()`.

### 31. [PDTS] POSIX guarantees atomicity for `rename()`

Section: X 15.30 [fs.op.rename] Status: NAD Submitter: CH-18 Opened: 2014-01-20 Last modified: 2014-04-18

View all issues with NAD status.

Discussion:

POSIX guarantees some kind of atomicity for `rename()`.

Clarify that POSIX' `rename()` guarantee "If the `rename()` function fails for any reason other than [EIO], any file named by new shall be unaffected." holds for C++ as well.

[2014-02-10 Beman Dawes]

Section 2.1, POSIX conformance, [fs.conform.9945] specifies the POSIX conformance requirements for TS implementations in carefully crafted and specific detail. Repeating a portion of the POSIX standard's specification for a particular TS function would do great harm as it would bring into question all of the portions of the POSIX specification for the function that were not repeated.

Furthermore, all the caveats and other details of the 2.1 specification would have to be analyzed and possibly appended; it ties the hands of implementors if they are not given latitude to deviate as needed when working with non-POSIX operating systems.

I strongly recommend NAD for this issue.

[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]

Proposed resolution:

### 39. [PDTS] `permissions()` is missing from synopsis

Section: X 6 [fs.filesystem.synopsis] Status: NAD Editorial Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

Discussion:

permissions function is missing from the summary list.

Proposed resolution:

[2014-02-07: Beman Dawes comments: Fixed as Editorial.]

### 43. [PDTS] `path::compare(const string&)` should be `path::compare(const string_type&)`

Section: X 8 [class.path] Status: Dup Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-18

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

View all issues with Dup status.

Discussion:

`path::compare(const string&)` should be `path::compare(const string_type&)`.

[2014-02-08 Daniel comments]

This issue is a duplicate of 50. The suggested wording of that issue would resolve this issue here as well.

[2014-02-13 LWG/SG-3 Issaquah: Agrees with Daniel.]

Proposed resolution:

### 46. [PDTS] Do we really need `generic*`?

Section: X 8.4.7 [path.generic.obs] Status: NAD Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2014-04-08

View all issues with NAD status.

Discussion:

Do we really need `generic*`?

[2014-02-08 Daniel comments]

These functions should exist for more than one reason.

First, the generic pathname format is a well-defined concept for the `path` specification and defining just a single way into a `path` but not out of it looks like an incomplete design.

More importantly, the existence of these functions have demonstrated to be quite useful in practice, because the generic pathname format concept is popular for many tools such as `maven` or the some configuration files for the Eclipse IDE do understand this syntax uniformly on all platforms and it allows to generate or modify such files using C++ code based on `filesystem::path`. The practical problem of the non-portable root-names doesn't matter in such contexts, because the serialized path names are in general relative names or depend on initial parts that are determined by properties or environment variables.

In other words: I'm recommending NAD for this issue.

[2014-02-13 LWG/SG-3 Issaquah: Withdrawn by submitter.]

Proposed resolution:

### 51. [PDTS] `directory_iterator`, `recursive_directory_iterator`, `pointer`/`reference` typedefs wrong

Section: X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] Status: Dup 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 Dup status.

Discussion:

`directory_iterator` and `recursive_directory_iterator` are constant iterators, but their `pointer`/`reference` typedefs are wrong (`std::iterator` defaults to providing modifiable ones).

[2014-02-08 Daniel comments]

I noticed the same problem when trying to resolve 52. The currently suggested wording for that issue should fix the here mentioned problem as well.

I recommend to solve this issue as "Resolved by the proposed wording for 52".

[2014-02-13 LWG/SG-3 Issaquah: Daniel's resolution accepted.]

Proposed resolution: