Doc. no. ----
Date: 2015-11-23
Project: Programming Language C++
Reply to: Beman Dawes <bdawes at acm dot org>

File System TS Active Issues List (Revision 4 Draft 1)

Revised 2015-11-23 at 13:11:31 UTC

Reference ISO/IEC TS 18822

Also see:

The purpose of this document is to record the status of issues which have come before the File System Study Group (SG3) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC TS 18822 document.

This document contains only study group issues which are actively being considered by the Study Group, i.e., issues which have a status of New, Open, Ready, or Review. See Defect Reports List for issues considered defects and Closed Issues List for issues considered closed.

The issues in these lists are not necessarily formal ISO Defect Reports (DR's). While some issues will eventually be elevated to official Defect Report status, other issues will be disposed of in other ways. See Issue Status.

This document includes [bracketed italicized notes] as a reminder to the SG3 of current progress on issues. Such notes are strictly unofficial and should be read with caution as they may be incomplete or incorrect. Be aware that SG3 support for a particular resolution can quickly change if new viewpoints or killer examples are presented in subsequent discussions.

For the most current official version of this document see http://www.open-std.org/jtc1/sc22/wg21/. Requests for further information about this document should include the document number above, reference ISO/IEC TS 18822, and be submitted to Information Technology Industry Council (ITI), 1250 Eye Street NW, Washington, DC 20005.

Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the comp.std.c++ FAQ.

How to submit an issue

  1. Mail your issue to the author of this list.
  2. Specify a short descriptive title. If you fail to do so, the subject line of your mail will be used as the issue title.
  3. If the "From" on your email is not the name you wish to appear as issue submitter, then specify issue submitter.
  4. Provide a brief discussion of the problem you wish to correct. Refer to the latest working draft or standard using [section.tag] and paragraph numbers where appropriate.
  5. Provide proposed wording. This should indicate exactly how you want the standard to be changed. General solution statements belong in the discussion area. This area contains very clear and specific directions on how to modify the current draft. If you are not sure how to word a solution, you may omit this part. But your chances of a successful issue greatly increase if you attempt wording.
  6. It is not necessary for you to use html markup. However, if you want to, you can <ins>insert text like this</ins> and <del>delete text like this</del>. The only strict requirement is to communicate clearly to the list maintainer exactly how you want your issue to look.
  7. It is not necessary for you to specify other html font/formatting mark-up, but if you do the list maintainer will attempt to respect your formatting wishes (as described by html markup, or other common idioms).
  8. It is not necessary for you to specify open date or last modified date (the date of your mail will be used).
  9. It is not necessary for you to cross reference other issues, but you can if you like. You do not need to form the hyperlinks when you do, the list maintainer will take care of that.
  10. One issue per email is best.
  11. Between the time you submit the issue, and the next mailing deadline (date at the top of the Revision History), you own this issue. You control the content, the stuff that is right, the stuff that is wrong, the format, the misspellings, etc. You can even make the issue disappear if you want. Just let the list maintainer know how you want it to look, and he will try his best to accommodate you. After the issue appears in an official mailing, you no longer enjoy exclusive ownership of it.

Revision History

Issue Status

Issues reported to the SG3 transition through a variety of statuses, indicating their progress towards a resolution. Typically, most issues will flow through the following stages.

New - The issue has not yet been reviewed by the SG3. Any Proposed Resolution is purely a suggestion from the issue submitter, and should not be construed as the view of SG3.

Open - The SG3 has discussed the issue but is not yet ready to move the issue forward. There are several possible reasons for open status:

A Proposed Resolution for an open issue is still not be construed as the view of SG3. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.

Review - Exact wording of a Proposed Resolution is now available for review on an issue for which the SG3 previously reached informal consensus.

Ready - The SG3 has reached consensus that the issue is a defect in the Standard, the Proposed Resolution is correct, and the issue is ready to forward to the full committee for further action as a Defect Report (DR).

Typically, an issue must have a proposed resolution in the currently published issues list, whose wording does not change during SG3 review, to move to the Ready status.

Voting - This status should not be seen in a published issues list, but is a marker for use during meetings to indicate an issues was Ready in the pre-meeting mailing, the Proposed Resolution is correct, and the issue will be offered to the working group at the end of the current meeting to apply to the current working paper (WP) or to close in some other appropriate manner. This easily distinguishes such issues from those moving to Ready status during the meeting itself, that should not be forwarded until the next meeting. If the issue does not move forward, it should fall back to one of the other open states before the next list is published.

Immediate - This status should not be seen in a published issues list, but is a marker for use during meetings to indicate an issues was not Ready in the pre-meeting mailing, but the Proposed Resolution is correct, and the issue will be offered to the working group at the end of the current meeting to apply to the current working paper (WP) or to close in some other appropriate manner. This status is used only rarely, typically for fixes that are both small and obvious, and usually within a meeting of the expected publication of a revised standard. If the issue does not move forward, it should fall back to one of the other open states before the next list is published.

In addition, there are a few ways to categorise and issue that remains open to a resolution within the library, but is not actively being worked on.

Deferred - The SG3 has discussed the issue, is not yet ready to move the issue forward, but neither does it deem the issue significant enough to delay publishing a standard or Technical Report. A typical deferred issue would be seeking to clarify wording that might be technically correct, but easily mis-read.

A Proposed Resolution for a deferred issue is still not be construed as the view of SG3. Comments on the current state of discussions are often given at the end of open issues in an italic font. Such comments are for information only and should not be given undue importance.

Core - The SG3 has discussed the issue, and feels that some key part of resolving the issue is better handled by a cleanup of the language in the Core part of the standard. The issue is passed to the Core Working Group, which should ideally open a corresponding issue that can be linked from the library issue. Such issues will be revisitted after Core have made (or declined to make) any changes.

EWG - The SG3 has discussed the issue, and wonder that some key part of resolving the issue is better handled by some (hopefully small) extension to the language. The issue is passed to the Evolution Working Group, which should ideally open a corresponding issue that can be linked from the library issue. Such issues will be revisitted after Evoltion have made (or declined to make) any recommendations. Positive recommendations from EWG will often mean the issue transition to Core status while we wait for some proposed new feature to land in the working paper.

Ultimately, all issues should reach closure with one of the following statuses.

DR - (Defect Report) - The full WG21/PL22.16 committee has voted to forward the issue to the Project Editor to be processed as a Potential Defect Report. The Project Editor reviews the issue, and then forwards it to the WG21 Convenor, who returns it to the full committee for final disposition. This issues list accords the status of DR to all these Defect Reports regardless of where they are in that process.

WP - (Working Paper) - The proposed resolution has not been accepted as a Technical Corrigendum, but the full WG21/PL22.16 committee has voted to apply the Defect Report's Proposed Resolution to the working paper.

C++11 - (C++ Standard, as revised for 2011) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into the published 2011 revision to the C++ standard, ISO/IEC TS 18822.

CD1 - (Committee Draft 2008) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into the Fall 2008 Committee Draft.

TC1 - (Technical Corrigenda 1) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution as a Technical Corrigenda. Action on this issue is thus complete and no further action is possible under ISO rules.

TRDec - (Decimal TR defect) - The SG3 has voted to accept the Defect Report's Proposed Resolution into the Decimal TR. Action on this issue is thus complete and no further action is expected.

Resolved - The SG3 has reached consensus that the issue is a defect in the Standard, but the resolution adopted to resolve the issue came via some other mechanism than this issue in the list - typically by applying a formal paper, occasionally as a side effect of consolidating several interacting issue resolutions into a single issue.

Dup - The SG3 has reached consensus that the issue is a duplicate of another issue, and will not be further dealt with. A Rationale identifies the duplicated issue's issue number.

NAD - The SG3 has reached consensus that the issue is not a defect in the Standard.

NAD Editorial - The SG3 has reached consensus that the issue can either be handled editorially, or is handled by a paper (usually linked to in the rationale).

NAD Future - In addition to the regular status, the SG3 believes that this issue should be revisited at the next revision of the standard.

NAD Concepts - This status reflects an evolution of the language during the development of C++11, where a new feature entered the language, called concepts, that fundamentally changed the way templates would be specified and written. While this language feature was removed towards the end of the C++11 project, there is a clear intent to revisit this part of the language design. During that development, a number of issues were opened against the updated library related to use of that feature, or requesting fixes that would require exliciit use of the concepts feature. All such issues have been closed with this status, and may be revisitted should this or a similar language feature return for a future standard.

Tentatively - This is a status qualifier. The issue has been reviewed online, or at an unofficial meeting, but not in an official meeting, and some support has been formed for the qualified status. Tentatively qualified issues may be moved to the unqualified status and forwarded to full committee (if Ready) within the same meeting. Unlike Ready issues, Tentatively Ready issues will be reviewed in subcommittee prior to forwarding to full committee. When a status is qualified with Tentatively, the issue is still considered active.

Pending - This is a status qualifier. When prepended to a status this indicates the issue has been processed by the committee, and a decision has been made to move the issue to the associated unqualified status. However for logistical reasons the indicated outcome of the issue has not yet appeared in the latest working paper.

Issues are always given the status of New when they first appear on the issues list. They may progress to Open or Review while the SG3 is actively working on them. When the SG3 has reached consensus on the disposition of an issue, the status will then change to Dup, NAD, or Ready as appropriate. Once the full PL22.16 committee votes to forward Ready issues to the Project Editor, they are given the status of Defect Report ( DR). These in turn may become the basis for Technical Corrigenda (TC1), or are closed without action other than a Record of Response (Resolved ). The intent of this SG3 process is that only issues which are truly defects in the Standard move to the formal ISO DR status.

Active Issues

63. Enable efficient retrieval of file size from directory_entry

Section: X [fs.op.file_size] Status: New Submitter: Gor Nishanov Opened: 2014-05-22 Last modified: 2015-11-23

View all issues with New status.

Discussion:

On Windows, the FindFileData _WIN32_FIND_DATA structure, which is the underlying data type for directory_entry, contains the file size as one of the fields. Thus efficient enumeration of files and getting their sizes is possible without doing a separate query for the file size.

[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]

[23 Nov 2015 Editorally correct name of data structure mentioned in discussion.]

Proposed resolution:

In section 12 Class directory_entry [class.directory_entry] add the following observer declarations: 

      uintmax_t file_size();
      uintmax_t file_size(error_code& ec) noexcept;

In section 12.3 directory_entry observers [directory_entry.obs] add the following: 

      uintmax_t file_size();
      uintmax_t file_size(error_code& ec) noexcept;

Returns: if *this contains a cached file size, return it. Otherwise return file_size(path()) or file_size(path(), ec) respectively.

Throws: As specified in Error reporting (7).

64. operator / (and other append) semantics not useful if argument has root

Section: X 8.4.3 [8.4.3], 8.6 [path.non-member] Status: New Submitter: Peter Dimov Opened: 2014-05-30 Last modified: 2014-07-05

View all issues with New status.

Discussion:

In a recent discussion on the Boost developers mailing list, the semantics of operator / and other append operations were questioned:

In brief, currently p1 / p2 is required to concatenate the lexical representation of p1 and p2, inserting a preferred separator as needed.

This means that, for example, "c:\x" / "d:\y" gives "c:\x\d:\y", and that "c:\x" / "\\server\share" gives "c:\x\\server\share". This is rarely, if ever, useful.

An alternative interpretation of p1 / p2 could be that it yields a path that is the approximation of what p2 would mean if interpreted in an environment in which p1 is the starting directory. Under this interpretation, "c:\x" / "d:\y" gives "d:\y", which is more likely to match what was intended.

I am not saying that this second interpretation is the right one, but I do say that we have reasons to suspect that the first one (lexical concatenation using a separator) may not be entirely correct. This leads me to think that the behavior of p1 / p2, when p2 has a root, needs to be left implementation-defined, so that implementations are not required to do the wrong thing, as above.

This change will not affect the ordinary use case in which p2 is a relative, root-less, path.

[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]

Proposed resolution:

65. remove_filename() post condition is incorrect

Section: X 4.8.5 [path.modifiers.remove_filename] Status: New Submitter: Eric Fiselier Opened: 2014-06-07 Last modified: 2014-07-05

View all issues with New status.

Discussion:

remove_filename() specifies !has_filename() as the post condition. This post condition is not correct. For example the path "/foo" has a filename of "foo". If we remove the filename we get "/", and "/" has a filename of "/".

[2014-06-08 Beman supplies an Effects: element.]

[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]

Proposed resolution:

    path& remove_filename();

Postcondition: !has_filename().

Effects: *this = parent_path(), except that if parent_path() == root_path(), clear().

Returns: *this.

[Example: 

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

—end example]

66. Bitmask operations should use bitmask terms

Section: X throughout Status: New Submitter: Jonathan Wakely Opened: 2014-06-30 Last modified: 2014-07-05

View all issues with New status.

Discussion:

C++14 17.5.2.1.3 Bitmask types [bitmask.types] paragraph 4 specifies:

The following terms apply to objects and values of bitmask types:

The TS should use these forms where applicable throughout the document.

Proposed resolution:

67. path::root_directory() description is confusing

Section: X 8.4.9 [path.decompose] Status: New Submitter: Jonathan Wakely Opened: 2014-07-03 Last modified: 2014-07-04

View all issues with New status.

Discussion:

8.4.9 [path.decompose] p5 says:

If root-directory is composed of slash name, slash is excluded from the returned string.

but the grammar says that root-directory is just slash so that makes no sense.

Proposed resolution:

Change 8.4.9 [path.decompose] as indicated: 

path root_directory() const;

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

If root-directory is composed of slash name, slash is excluded from the returned string.

68. path::operator+= is defined, but not operator+

Section: X 8 [class.path] Status: New Submitter: Jonathan Wakely Opened: 2014-07-03 Last modified: 2015-11-22

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

View all issues with New status.

Discussion:

This doesn't seem to be in Boost.Filesystem, so maybe it isn't needed, but since path += path2 works then it seems reasonable to expect path1 + path2 to work as well.

[04 Jul 2014 Beman Dawes comments:]

The 12 overloads required by basic_string operator+ scared me off, and I never came back to the issue.

[22 Nov 2015 Beman supplies proposed resolution wording.]

Proposed resolution:

NAD, Future.

It is not necessary to provide every possible string operation for class path because it is always possible to convert to a string, perform the operation, and convert back to a path. The most commonly needed string operations are provided for class path as a convenience, but every added function comes at the cost of increased interface complexity. In this case, the cost is judged to outweigh the convenience.

Future changes to the language, such as concepts, and changes to the library, such as basic_string_view, may allow reduction of the complexity of the class path interface. The LWG may wish to reconsider this issue at that time.

69. recursive_directory_iterator effects refers to non-existent functions

Section: X 14.1 [rec.dir.itr.members] ¶39 Status: New Submitter: Jonathan Wakely Opened: 2014-07-10 Last modified: 2014-10-08

View all issues with New status.

Discussion:

operator++/increment, second bullet item, says "Otherwise if recursion_pending() && is_directory(this->status()) && (!is_symlink(this->symlink_status())..." but recursive_directory_iterator does not have status or symlink_status members.

Proposed resolution:

Change 14.1 [rec.dir.itr.members] ¶39 as indicated:

Otherwise if recursion_pending() && is_directory((*this)->status()) && (!is_symlink((*this)->symlink_status()) ..."

70. system_complete refers to undefined variable 'base'

Section: X 15.36 [fs.op.system_complete] Status: New Submitter: Jonathan Wakely Opened: 2014-07-20 Last modified: 2014-10-08

View all other issues in 15.36 [fs.op.system_complete].

View all issues with New status.

Discussion:

The example says "...or p and base have the same root_name().", but base is not defined. I believe it refers to the value returned by current_path().

Proposed resolution:

Change 15.36 [fs.op.system_complete] as indicated:

For Windows based operating systems, system_complete(p) has the same semantics as absolute(p, current_path()) if p.is_absolute() || !p.has_root_name() or p and base current_path() have the same root_name(). Otherwise it acts like absolute(p, cwd) is the current directory for the p.root_name() drive. This will be the current directory for that drive the last time it was set, and thus may be residue left over from a prior program run by the command processor. Although these semantics are useful, they may be surprising.

71. Errors in Copy

Section: X 15.3 [fs.op.copy] Status: New Submitter: Jonathan Wakely Opened: 2014-07-28 Last modified: 2014-10-08

View all other issues in 15.3 [fs.op.copy].

View all issues with New status.

Discussion:

15.3 [fs.op.copy] paragraph 16 says:

Otherwise if !exists(t) & (options & copy_options::copy_symlinks) != copy_options::none, then copy_symlink(from, to, options).

But there is no overload of copy_symlink that takes a copy_options; it should be copy_symlink(from, to).

15.3 [fs.op.copy] Paragraph 26 says:

as if by for (directory_entry& x : directory_iterator(from))

but the result of dereferencing a directory_iterator is const; it should be:

as if by for (const directory_entry& x : directory_iterator(from))

Proposed resolution:

Change 15.3 [fs.op.copy] paragraph 16 as indicated:

Otherwise if !exists(t) & (options & copy_options::copy_symlinks) != copy_options::none , then copy_symlink(from, to, options).

Change 15.3 [fs.op.copy] paragraph 26 as indicated:

as if by for (const directory_entry& x : directory_iterator(from))

72. Should is_empty use error_code in its specification?

Section: X 15.19 [fs.op.is_empty] Status: New Submitter: Jonathan Wakely Opened: 2014-08-01 Last modified: 2014-10-09

View all issues with New status.

Discussion:

The descriptions of most functions are explicit about the use of the ec argument, either saying something like "foo(p) or foo(p, ec), respectively" or using the ec argument like foo(p[, ec]), but is_empty does not.

[fs.op.is_empty]/2 refers to ec unconditionally, but more importantly [fs.op.is_empty]/3 doesn't pass ec to the directory_iterator constructor or the file_size function.

[ 9 Oct 2014 Beman supplies proposed wording. ]

Proposed resolution:

    bool is_empty(const path& p);
    bool is_empty(const path& p, error_code& ec) noexcept;

Effects:

Remarks: The temporary objects described in Effects are for exposition only. Implementations are not required to create them.

Returns: is_directory(s) ? directory_iterator(p) == directory_iterator() : file_size(p) == 0; See Effects.

The signature with argument ec returns false if an error occurs.

Throws: As specified in Error reporting (7).

73. status() effects cannot be implemented as specified

Section: X 15.33 [fs.op.status] Status: New Submitter: Jonathan Wakely Opened: 2015-09-15 Last modified: 2015-09-18

View all issues with New status.

Discussion:

[fs.op.status] paragraph 2 says:

Effects: As if:

error_code ec;
file_status result = status(p, ec);
if (result == file_type::none)
...

This won't compile, there is no comparison operator for file_status and file_type, and the conversion from file_type to file_status is explicit.

Proposed resolution:

Change [fs.op.status] paragraph 2:

Effects: As if:

error_code ec;
file_status result = status(p, ec);
if (result.type() == file_type::none)
...

74. Bidirectional iterator requirement on path::iterator is very expensive

Section: X 8.5 [path.itr] Status: New Submitter: Jonathan Wakely Opened: 2015-09-15 Last modified: 2015-11-22

View all issues with New status.

Discussion:

[path.itr] requires path::iterator to be a BidirectionalIterator, which also implies the ForwardIterator requirement in [forward.iterators] p6 for the following assertion to pass:

path p("/");
auto it1 = p.begin();
auto it2 = p.begin();
assert( &*it1 == &*it2 );

This prevents iterators containing a path, or constructing one on the fly when dereferenced, the object they point to must exist outside the iterators and potentially outlive them. The only practical way to meet the requirement is for p to hold a container of child path objects so the iterators can refer to those children. This makes a path object much larger than would naïvely be expected.

The Boost and MSVC implementations of Filesystem fail to meet this requirement. The GCC implementation meets it, but it makes sizeof(path) == 64 (for 64-bit) or sizeof(path) == 40 for 32-bit, and makes many path operations more expensive.

[21 Nov 2015 Beman comments:]

The ForwardIterator requirement in [forward.iterators] "If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object." will be removed by N4560, Working Draft, C++ Extensions for Ranges. I see no point in requiring something for the File System TS that is expensive, has never to my knowledge been requested by users, and is going to go away soon anyhow. The wording I propose below removes the requirement.

Proposed resolution:

Change [path.itr] paragraph 2:

A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (C++14 §24.1.4 Bidirectional iterators) except that there is no requirement that two equal iterators be bound to the same object. Its value_type is path.