<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8"> 
<title>Closed Issues List</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">N4004</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-05-24</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Beman Dawes &lt;<a href="mailto:bdawes at acm dot org">bdawes at acm dot org</a>&gt;</td>
</tr>
</table>
<h1>File System TS Closed Issues List (Revision R1)</h1>
<p><p>Revised 2014-05-24 at 12:05:47 UTC</p>
</p>
  <p>Reference ISO/IEC TS 18822</p>
  <p>Also see:</p>
    <ul>
      <li><a href="toc.html">Table of Contents</a> for all SG3 issues.</li>
      <li><a href="section-index.html">Index by Section</a> for all SG3 issues.</li>
      <li><a href="status-index.html">Index by Status</a> for all SG3 issues.</li>
      <li><a href="active.html"><replace "doc_name"/> Active Issues List</a></li>
      <li><a href="defects.html"><replace "doc_name"/> Defect Reports List</a></li>
    </ul>

  <p>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 <a href="active.html#Dup">Dup</a> or
  <a href="active.html#NAD">NAD</a>. See the <a href="active.html"><replace "doc_name"/> Active Issues List</a> active issues and more
  information. See the <a href="defects.html"><replace "doc_name"/> Defect Reports List</a> for issues considered
  defects.  The introductory material in that document also applies to
  this document.</p>

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

<h2>Closed Issues</h2>
<hr>
<h3><a name="10"></a>10. [PDTS] Apparently inconsistent return types from several functions</h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> FI-4 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-18</p>
<p><b>View other</b> <a href="open-index.html# [fs.filesystem.synopsis">active issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all other</b> <a href="section-index.html# [fs.filesystem.synopsis">issues</a> in 6 [fs.filesystem.synopsis].</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is unclear why <tt>copy</tt>, <tt>copy_file</tt> and <tt>copy_symlink</tt> have different return types,
and why the attribute-version of <tt>create_directory</tt> has a different return type than the
<tt>create_directory</tt> that takes no attributes. The status/error reporting in these functions
seems inconsistent.
<p/>
Resolution:
<p/>
Make the status/error reporting consistent or add a note explaining why it's different.
</p>

  <p><i>[
    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. <tt>create_directory</tt> has
    an inconsistent return type between the synopsis and the description.
    This has subsequently been corrected editorially.
  ]</i></p>





<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="12"></a>12. [PDTS] <tt>uintmax_t</tt> too small for large file sizes</h3>
<p><b>Section:</b> X [fs.filesystem.synopsis], [fs.op.file_size] <b>Status:</b> <a href="active.html#NAD Future">NAD Future</a>
 <b>Submitter:</b> CH-8 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-18</p>
<p><b>Discussion:</b></p>
<p><tt>uintmax_t</tt> is specified to hold at least 64 bit. This is not enough for sizes
beyond 4 [sic] exabytes.</p>

<p>Specify whether an implementation must provide a <tt>uintmax_t</tt> that can hold the maximum
possible space and file size values.</p>

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

  <p>
    <i>[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.]</i>
  </p>

  <p><i>[
    2014-02-11 Issaquah: NAD Future.
  ]</i></p>




<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="13"></a>13. [PDTS] Missing actual error conditions thrown</h3>
<p><b>Section:</b> X 7 [fs.err.report] etc. <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH 9 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-18</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
    <p>
      The specification of the actual error conditions for the functions that specify
      Throws: As specified in Error reporting. is missing.
    </p>

    <p>Add those specifications.</p>

    <p><i>[2014-02-07, Beman Dawes comments]</i></p>


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

    <p><i>[2014-02-11 Issaquah]</i></p>

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

  

<p><b>Proposed resolution:</b></p>








<hr>
<h3><a name="17"></a>17. [PDTS] <tt>path</tt> member <tt>swap()</tt> unnecessary</h3>
<p><b>Section:</b> X 8.4.5 [path.modifiers] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-12 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-18</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>As we have move semantics, member <tt>swap</tt> functions shouldn't be necessary any more.</p>
  
  <p><i>[2014-02-12 LWG/SG-3 Issaquah ]</i></p>

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


<p><b>Proposed resolution:</b></p>
<p>Remove <tt>swap()</tt>.</p>





<hr>
<h3><a name="23"></a>23. [PDTS] Request for <tt>create_regular_file()</tt> and/or <tt>touch()</tt></h3>
<p><b>Section:</b> X 15 <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-14 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-08</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Since <tt>create_symlink()</tt>, <tt>create_hardlink()</tt>, and <tt>create_directory()</tt> exist, there's
no reason not to have a <tt>create_regular_file()</tt> function.
</p>
<p>
Consider adding a function <tt>create_regular_file()</tt> with the behaviour of the POSIX <tt>touch</tt>
command.
</p>

<p><i>[Beman comments]</i></p>

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

<p>I have often wanted <tt>create_regular_file()</tt> but never got around to adding it.</p>

<p>While <tt>touch</tt> 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.</p>

<p>Whether or not it is appropriate to add operational functions this late in the PDTS
process is questionable.</p>
  
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: No consensus for change at this time.]</i></p>
 
  


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="26"></a>26. [PDTS] Equivalence is a volatile property</h3>
<p><b>Section:</b> X 15.13 [fs.op.equivalent] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-16 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-08</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Equivalence is a volatile property.</p>

<p>Consider adding a note that equivalence cannot be determined race-free.</p>

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

  


<p><b>Proposed resolution:</b></p>
  





<hr>
<h3><a name="28"></a>28. [PDTS] Possible <tt>last_write_time()</tt> postcondition?</h3>
<p><b>Section:</b> X 15.25 [fs.op.last_write_time] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> GB-15 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-08</p>
<p><b>View all other</b> <a href="section-index.html#5.25 [fs.op.last_write_time">issues</a> in 15.25 [fs.op.last_write_time].</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>The constraint on <tt>last_write_time</tt> is too weak: It is noted that the postcondition
of <tt>last_write_time(p) == new_time</tt> is not specified since it might not hold for file
systems with coarse time granularity.
<p/>
However, might it be possible to have a postcondition that <tt>last_write_time(p) &lt;= new_time</tt> ?</p>

<p>Add postcondition: <tt>last_write_time(p) &lt;= new_time</tt></p>

  <p><i>[2014-02-09, Beman Dawes comments:]</i></p>

  <p/>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.
  
<p><i>[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]</i></p>
 



<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="30"></a>30. [PDTS] <tt>remove()</tt> must avoid race</h3>
<p><b>Section:</b> X 15.28 [fs.op.remove] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-17 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-08</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>The specification can be read to require the existence test. As this introduces a
race, the existence test must not happen.</p>
<p>Change to: "Effects: <tt>p</tt> is removed as if by POSIX <tt>remove()</tt>."</p>

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


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wiki.edg.com/twiki/pub/Wg21issaquah/SG3/working-draft.html">SG3 working draft</a>.</p>

<ol><li><p>Change X 15.28 [fs.op.remove] as indicated:</p>

<blockquote><p>
<i>Effects</i>: <del>If <tt>exists(symlink_status(p,ec))</tt>, it</del><ins><tt>p</tt></ins> is removed as if by POSIX <tt>remove()</tt>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="31"></a>31. [PDTS] POSIX guarantees atomicity for <tt>rename()</tt></h3>
<p><b>Section:</b> X 15.30 [fs.op.rename] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-18 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-04-18</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>POSIX guarantees some kind of atomicity for <tt>rename()</tt>.</p>

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

  <p><i>[2014-02-10 Beman Dawes]</i></p>


  <p/>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.
  
  <p/>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.
  
  <p/>I strongly recommend NAD for this issue.
  
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: No consensus for change.]</i></p>

  


<p><b>Proposed resolution:</b></p>





<hr>
<h3><a name="39"></a>39. [PDTS] <tt>permissions()</tt> is missing from synopsis</h3>
<p><b>Section:</b> X 6  [fs.filesystem.synopsis] <b>Status:</b> <a href="active.html#NAD Editorial">NAD Editorial</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-04-18</p>
<p><b>Discussion:</b></p>
<p>permissions function is missing from the summary list.</p>


<p><b>Proposed resolution:</b></p>
<p>
  <i>[2014-02-07: Beman Dawes comments: Fixed as Editorial.]</i>
</p>





<hr>
<h3><a name="43"></a>43. [PDTS] <tt>path::compare(const string&amp;)</tt> should be <tt>path::compare(const string_type&amp;)</tt></h3>
<p><b>Section:</b> X 8 [class.path] <b>Status:</b> <a href="active.html#Dup">Dup</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-04-18</p>
<p><b>View all other</b> <a href="section-index.html# [class.path">issues</a> in 8 [class.path].</p>
<p><b>View all issues with</b> <a href="status-index.html#Dup">Dup</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>path::compare(const string&amp;)</tt> should be <tt>path::compare(const string_type&amp;)</tt>.
</p>

<p><i>[2014-02-08 Daniel comments]</i></p>


<p>
This issue is a duplicate of <a href="defects.html#50">50</a>. The suggested wording of that issue would resolve this issue here as well.
</p>
  
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Agrees with Daniel.]</i></p>




<p><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="46"></a>46. [PDTS] Do we really need <tt>generic*</tt>?</h3>
<p><b>Section:</b> X 8.4.7 [path.generic.obs] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> P.J. Plauger <b>Opened:</b> 2014-01-30 <b>Last modified:</b> 2014-04-08</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Do we really need <tt>generic*</tt>?</p>

<p><i>[2014-02-08 Daniel comments]</i></p>

<p>
These functions should exist for more than one reason.
<p/>
First, the <i>generic pathname format</i> is a well-defined concept for the <tt>path</tt> specification
and defining just a single way into a <tt>path</tt> but not out of it looks like an incomplete design.
<p/>
More importantly, the existence of these functions have demonstrated to be quite useful in practice,
because the <i>generic pathname format</i> concept is popular for many tools such as <tt>maven</tt>
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 <tt>filesystem::path</tt>. 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.
<p/>
In other words: I'm recommending NAD for this issue.
</p>
  
<p><i>[2014-02-13 LWG/SG-3 Issaquah: Withdrawn by submitter.]</i></p>





<p><b>Proposed resolution:</b></p>
<p></p>





<hr>
<h3><a name="51"></a>51. [PDTS] <tt>directory_iterator</tt>, <tt>recursive_directory_iterator</tt>, <tt>pointer</tt>/<tt>reference</tt> typedefs wrong</h3>
<p><b>Section:</b> X 13 [class.directory_iterator], X 14 [class.rec.dir.itr] <b>Status:</b> <a href="active.html#Dup">Dup</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-02-03 <b>Last modified:</b> 2014-04-18</p>
<p><b>View all other</b> <a href="section-index.html#3 [class.directory_iterator">issues</a> in 13 [class.directory_iterator].</p>
<p><b>View all issues with</b> <a href="status-index.html#Dup">Dup</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>directory_iterator</tt> and <tt>recursive_directory_iterator</tt> are constant iterators, but their
<tt>pointer</tt>/<tt>reference</tt> typedefs are wrong (<tt>std::iterator</tt> defaults to providing modifiable
ones).</p>

<p><i>[2014-02-08 Daniel comments]</i></p>

<p>
I noticed the same problem when trying to resolve <a href="defects.html#52">52</a>. The currently suggested wording for that
issue should fix the here mentioned problem as well.
<p/>
I recommend to solve this issue as "Resolved by the proposed wording for <a href="defects.html#52">52</a>".
</p>
  <p><i>[2014-02-13 LWG/SG-3 Issaquah: Daniel's resolution accepted.]</i></p>



<p><b>Proposed resolution:</b></p>
<p></p>





</body>
</html>
