<!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">
  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">N4212</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2014-10-11</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 R3)</h1>
<p><p>Revised 2014-10-11 at 18:10:45 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>R3: 2014-10-10 SG-3 File System TS<ul>
<li><b>Summary:</b><ul>
<li>10 open issues, up by 4.</li>
<li>61 closed issues, up by 0.</li>
<li>71 issues total, up by 4.</li>
</ul></li>
<li><b>Details:</b><ul>
<li>Added the following 4 New issues: <a href="active.html#69">69</a>, <a href="active.html#70">70</a>, <a href="active.html#71">71</a>, <a href="active.html#72">72</a>.</li>
<li>No issues changed.</li>
</ul></li>
</ul>
</li>
</ul>

<h2>Closed Issues</h2>
<hr>
<h3><a name="4"></a>4. [PDTS] Need definition of dot and dot-dot</h3>
<p><b>Section:</b> X 4.14 [fs.def.parent] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> CH-3 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-05</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 concept of a parent directory for dot or dotdot exists, but the definition doesn't apply.</p>

<p>Suggested action:</p>

<p>Remove the paragraph. This concept does not apply to dot and dot-dot. Add a definition for dot and dot-dot.</p>

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

<p>Suggest it is editorial and should be passed to the project editor.</p>

  <p><i>[
    2014-02-11 Issaquah: Beman to provide wording for review next meeting. Also see related issue 5.
  ]</i></p>


  <p><i>[22 May 2014 Beman Dawes comments:]</i></p>

  <blockquote>
    <p>I've now reviewed this issue carefully and believe it is NAD. "parent" is used in four places in the WP,
    and so deserves a definition. The current definition is copied word-for-word and in its entirety from the
    POSIX definition. I believe strongly that the File System TS needs to stay in alignment with POSIX on
    this matter,
    and that the best way to do that is simply to use the POSIX wording.</p>
  </blockquote>

  <p><i>[17 Jun 2014 Rapperswil LWG closes as NAD. No concensus for change.]</i></p>

  


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





<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-06-27</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="11"></a>11. [PDTS] Lack of <tt>relative()</tt> operation function</h3>
<p><b>Section:</b> X 6 &amp; 15 <b>Status:</b> <a href="active.html#NAD Future">NAD Future</a>
 <b>Submitter:</b> GB-1 <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-05</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD Future">NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is no <tt>relative()</tt> operation, to complement both <tt>absolute()</tt>
 and <tt>canonical()</tt>
</p>
<p>
The TS introduces relative paths. 
</p>

<ul>
  <li>
    <p>
      They are defined in section 4.18
      relative path [fs.def.relative-path]
    </p> </li>
  <li>
    <p>
      A decomposition method

      <tt>relative_path()</tt>
      is described in section 8.4.9 path decomposition [path.decompose]
    </p> 
  </li>
  <li>
  <p>
  
  Two query methods to determine if a path 
  either <tt>has_relative_path()</tt> or 
  <tt>is_relative()</tt> described in 8.4.10 path query [path.query] </p>
</li>
</ul>
<p>
However there is no way to create a relative path as a path relative to another. 
Methods are provided to create absolute and canonical paths.
</p>
<p>

In section 15.1 Absolute [fs.op.absolute]:</p>
<p>

path absolute(const 
path&amp; 
p,
const 
path&amp; 
base=current_path());</p>
<p>

and in section 15.2 Canonical [fs.op.canonical]</p>
<p>

path canonical(const 
path&amp; 
p,
const 
path&amp; 
base = 
current_path());</p>
<p>

path canonical(const 
path&amp; 
p, 
error_code&amp; 
ec);</p>
<p>

path canonical(const 
path&amp; 
p,
const 
path&amp; 
base, 
error_code&amp; 
ec);</p>
<p>
By providing a 
operations to achieve absolute and canonical paths there is no impediment to 
providing a similar operation 

relative() 
that
attempts to return a new path relative to 
some base path.</p>
<p>

For example:</p>
<p>

path relative(const 
path&amp; 
p,
const 
path&amp; 
to = 
current_path());</p>
<p>

path relative(const 
path&amp; 
p, 
error_code&amp; 
ec);</p>
<p>

path relative(const 
path&amp; 
p,
const 
path&amp; 
to, 
error_code&amp; 
ec);</p>
<p>

This would return a 
path, if possible, that is relative to 

to. 
The implementation can make use of 

absolute() 
and 
canonical() 
to determine the relative path, if it exists.</p>
<p>

The File System TS is 
based on the 
<a href="http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/index.htm">

<u>&#8203;</u></a><a href="http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/index.htm">boost::filesystem 
library</a> and it too suffers from this anomaly. There are open tickets for 
this in 
<a href="https://svn.boost.org/">

<u>&#8203;</u></a><a href="https://svn.boost.org/">Boost 
Trac</a>:</p>
<ul>
  <li>
  <p>
  
  <a href="https://svn.boost.org/trac/boost/ticket/5897">
  <u>&#8203;</u></a><a href="https://svn.boost.org/trac/boost/ticket/5897">#5897 
  Make path relative function</a>
  </p>
</li>
  <li>
  <p>
  
  <a href="https://svn.boost.org/trac/boost/ticket/1976">
  <u>&#8203;</u></a><a href="https://svn.boost.org/trac/boost/ticket/1976">#1976 
  Inverse function for complete</a>
  </p>
</li>
</ul>
<p>

and it is the subject of several posts on StackOverflow for example:</p>
<ul>
  <li>
  <p>
  
  <a href="http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path">
  <u>&#8203;</u></a><a href="http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path">http://stackoverflow.com/questions/10167382/boostfilesystem-get-relative-path</a>
  </p>
</li>
  <li>
  <p>
  
  <a href="http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths">
  <u>&#8203;</u></a><a href="http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths">http://stackoverflow.com/questions/5772992/get-relative-path-from-two-absolute-paths</a>
  </p>
</li>
</ul>
<p>

Other languages typically provide a similar function. For example python 
provides:</p>
<p>

os.path.relpath(path[, 
start])</p>
<p>

Return a relative 
filepath to 
path 
either from the current directory or from an optional 

start 
directory. This is a path computation: the filesystem is not accessed to confirm 
the existence or nature of 
path 
or 
start.
start 
defaults to 
os.curdir.</p>

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


<p>A <code>relative()</code> function is useful and much requested.
I've seen such a function provided by users and have written it myself in app code.
It is one of those things I've been meaning to do for years, and have just never gotten around to.</p>

  <p>That said, my mild preference is to treat this as "NAD, Future" for File System TS1,
  but treat it as a priority for TS2.</p>

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

<p>
 The LWG/SG-3 voted strongly in favor of adding this functionality, and doing so in
    this TS. That implies quite a bit of work before the next meeting to validate that the proposed interface
    works as desired for various platforms. There was general agreement not to hold FS STS1 if this functionality
    isn't ready when the rest of the TS is ready.
</p>

<p><i>[2014-05-19 Beman Dawes supplied wording. The design benefited from discussions with Jamie Allsop, who was
the source of the original NB comment.
Thanks to Bjorn Reese for corrections and suggestions.  Although there was also discussion and experimentation with additional
relative functions that took into account symlinks and normalization, these are not proposed here since even the proponents
of such functions were unsure of appropriate semantics.]</i></p>


  <p><i>[17 Jun 2014 Rapperswil LWG closes as NAD, Future. Although there is strong concensus for eventually
  providing both lexical and existence based flavors of relative() functionality, discussion of the many possible
  design choices led to the conclusion that more research and actual user experience is necessary before
  moving forward. Interested parties should submit papers.]</i></p>

  


  <p>
    <b>Original proposed resolution:</b>
  </p>
<ol>
<li>
<p>Modify header <tt>&lt;filesystem&gt;</tt> synopsis, 6 [fs.filesystem.synopsis],
by adding the operational functions after <tt>canonical</tt>:</p>
<blockquote><pre>
path relative(const path&amp; p, const path&amp; to = current_path());
path relative(const path&amp; p, error_code&amp; ec);
path relative(const path&amp; p, const path&amp; to, error_code&amp; ec);
</pre></blockquote>
</li>
<li><p>Insert the section:</p>
<blockquote><p>
15.3 Relative [fs.op.relative]
</p>
<pre>
path relative(const path&amp; p, const path&amp; to = current_path());
path relative(const path&amp; p, error_code&amp; ec);
path relative(const path&amp; p, const path&amp; to, error_code&amp; ec);</pre>
<blockquote>
<p><i>Overview</i>: Return a relative path of p to the current directory or from an optional to path.</p>
<p><i>Returns</i>: A relative path such that <tt>canonical(to)/relative(p,to) == canonical(p)</tt>,
otherwise <tt>path()</tt>. If <tt>canonical(to) == canonical(p)</tt> the path <tt>path(".")</tt> is returned. For the
overload without a <tt>to</tt> argument, <tt>to</tt> is <tt>current_path()</tt>. Signatures with argument <tt>ec</tt> return
<tt>path()</tt> if an error occurs.
</p>
<p>
<i>Throws</i>: As specified in Error reporting.</p>
<p>
<i>Remarks</i>: <tt>!exists(p) or !exists(to) or !is_directory(to)</tt> is an error.
</p>
</blockquote></blockquote>
<p>
and bump all following sections up by 0.1. Update the contents and any cross-references
accordingly.
</p>
</li>
</ol>
<p>
Question: Should Returns be specified in terms of equivalence? For example:
<tt>equivalent( canonical(to)/relative(p,to), canonical(p) )</tt>
</p>
<p>
Question: Should <tt>canonical(to) == canonical(p)</tt> return <tt>path(".")</tt> or <tt>path()</tt>? Why?
</p>
<p>

Question: Should <tt>to</tt> be spelled <tt>start</tt>?</p>
  
<p><b>Proposed resolution:</b></p>

  <p>
    <i>
      To 6 Header &lt;experimental/filesystem&gt; synopsis [fs.filesystem.synopsis],
      add:
    </i>
  </p>
  <blockquote>
    <pre style="background-color: #D7EEFF">path lexically_relative(const path&amp; p, const path&amp; base);</pre>
  </blockquote>

  <p>
    <i>At the end of 8.6 path non-member functions [path.non-member], add </i>
  </p>
  <blockquote>

    <h4>
      8.6.3  <code>path</code>
      <a style="text-decoration: none" name="path-lexically-relative">lexically_relative</a> function [path.lexically.relative]
    </h4>
    <pre style="background-color: #D7EEFF">path lexically_relative(const path&amp; p, const path&amp; base);</pre>
    <blockquote>
      <p>
        Creates a path from the trailing elements of <code>p</code> that are
        lexically relative to <code>base</code>, which must be a prefix of <code>p</code>.
      </p>
      <p>
        <i>Effects:</i> If the number of elements in [<code>
          p.begin(),
          p.end()
        </code>) is less than or equal to the number of elements in [<code>
          base.begin(),
          base.end()
        </code>), or if any element in [<code>base.begin(), base.end()</code>)
        is not equal to the corresponding element in [<code>p.begin(), p.end()</code>),
        throw an exception of type <code>filesystem_error</code>.
      </p>
      <p>
        <i>Remarks: </i>Equality or inequality are determined by <code>
          path::operator==
        </code> or <code>path::operator!=</code> respectively.
      </p>
      <p>
        <i>Returns: </i>An object of class <code>path</code> containing the first element of <code>p</code> that does not have a
        corresponding element in <code>base,</code> followed by the subsequent elements
        of <code>p</code> appended as if by <code>path::operator/=</code>.
      </p>
      <p>
        <i>Throws:</i> <code>filesystem_error</code>.
      </p>
      <p>
        [<i>Note:</i> Behavior is determined by the
        lexical value of the elements of <code>p</code> and <code>base</code> - the
        external file system is not accessed. The&nbsp;case where an element of <code>
          base
        </code>
        is not equal to corresponding element of <code>p</code> is treated as an error to avoid returning an incorrect result
        in the event of symlinks.&nbsp; <i>--end note</i>]
      </p>
    </blockquote>
    <p>
      <i>
        <span style="background-color: #CCCCCC">
          A possible implementation would
          be:
        </span>
      </i>
    </p>
    <blockquote>
      <pre>
        <span style="background-color: #CCCCCC">
auto mm = std::mismatch( p.begin(), p.end(), base.begin(), base.end());
if (mm.first == p.end() || mm.second != base.end())
{
throw filesystem_error(
&quot;p does not begin with base, so can not be made relative to base&quot;,
p, base,
error_code(errc::invalid_argument, generic_category()));
}
path tmp(*mm.first++);
for (; mm.first != p.end(); ++mm.first)
tmp /= *mm.first;
return tmp;</span></pre>

    </blockquote>

  </blockquote>







<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-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD Future">NAD Future</a> status.</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-06-27</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-06-27</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-05-24</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-05-24</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-05-24</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-05-24</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-06-27</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="38"></a>38. [PDTS] Make certain functions <tt>noexcept</tt> and drop <tt>error_code</tt> version</h3>
<p><b>Section:</b> X 12.3 [directory_entry.obs], X 15.12 [fs.op.exists], X 15.16 [fs.op.is_block_file], X 15.17 [fs.op.is_char_file], X 15.18 [fs.op.is_directory], X 15.19 [fs.op.is_empty], X 15.20 [fs.op.is_fifo], X 15.21 [fs.op.is_other], X 15.22 [fs.op.is_regular_file], X 15.23 [fs.op.is_socket], X 15.24 [fs.op.is_symlink], X 15.33 [fs.op.status], X 15.35 [fs.op.symlink_status], X 15.38 [fs.op.unique_path] <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-07-05</p>
<p><b>View all other</b> <a href="section-index.html#2.3 [directory_entry.obs">issues</a> in 12.3 [directory_entry.obs].</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>exists(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>is_*(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>status(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>symlink_status(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>file_status::status()</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>file_status::symlink_status()</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).<br/>
<tt>unique_path(const path&amp;)</tt> should be <tt>noexcept</tt> (drop <tt>error_code</tt> version).
</p>

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

<p>
<tt>unique_path(const path&amp;)</tt> cannot be declared as <tt>noexcept</tt>, because it returns an object
during whose construction a memory allocation request may fail, see the rationale provided in <a href="defects.html#37">37</a>.
<p/>
<tt>exists(const path&amp;)</tt> and the <tt>is_*(const path&amp;)</tt> functions cannot be <tt>noexcept</tt>, because 
they are specified in terms of <tt>status(const path&amp;)</tt>, which again may throw an exception, which is explicitly 
described in the Effects (<tt>filesystem_error</tt>), because the non-throwing function (<tt>status(const path&amp;, error_code&amp;)</tt>) 
may fail to satisfy the request.
<p/>
<tt>symlink_status(const path&amp;)</tt> may throw an exception for similar reasons that <tt>status(const path&amp;)</tt>
could fail.
<p/>
The reference to <tt>file_status::status()/symlink_status()</tt> looks like a typo to me (there are no such functions
in <tt>file_status</tt>), presumably <tt>directory_entry::status()/symlink_status()</tt> was meant. In this case I see 
no reason how these could be marked as <tt>noexcept</tt>, because these functions all may fail and may throw an exception.
<p/>
Based on this interpretation of the issue discussion I recommend to resolve this issue as NAD.
</p>

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


  <p/>Issues <a href="active.html#37">37</a>,
  <a href="active.html#38">38</a>,
  <a href="active.html#41">41</a>,
  and <a href="active.html#49">49</a> are concerned with signatures which should or should not
  be <tt>noexcept</tt>. I will provide unified proposed wording for these issues, possibly in a separate paper.
  
  <p><i>[17 Jun 2014 Rapperswil LWG closes as NAD. Working paper correct as written.]</i></p>

  


<p><b>Proposed resolution:</b></p>
<p></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-06-27</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD Editorial">NAD Editorial</a> status.</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="42"></a>42. 
[PDTS] <tt>class path</tt> should have defaulted constructors/destructor/assignments.
</h3>
<p><b>Section:</b> X 8 [class.path] <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-07-05</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#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>class path</tt> should have defaulted constructors/destructor/assignments.
</p>

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


<p/>Suggest NAD. Earlier versions did have defaulted constructors/destructor/assignments,
but they were removed at the request of Alberto Ganesh Barbati (c++std-filesys January 8, 2013):

<blockquote>
<p/>Speaking of <tt>=default</tt>, we have to be careful not over-constrain the specification.
I mean, if we just specify the intended meaning of those function with proper wording,
the implementation is allowed to use <tt>=default</tt> in case it provides an equivalent behaviour,
but if we put <tt>=default</tt> in the specification, the implementation is required to use it.
However, we have to remember that "for exposition only" data members may not be an
exhaustive list and that 17.5.2.3/2 allows implementations to provide an equivalent
behaviour using different members for which "default" construction/copy/assignment
may not be appropriate.

<p/><tt>=default</tt> is what we want for tuple, atomics, etc. It might be appropriate for
simple types like file_status, but, for more complex types like <tt>path</tt> itself,
I'd remove it and add proper wording.
</blockquote>
  <p><i>[17 Jun 2014 Rapperswil LWG closes as NAD. Ganesh's analysis is correct. WP correct as written.]</i></p>



<p><b>Proposed resolution:</b></p>
<p></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-06-27</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-05-24</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-06-27</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>





<hr>
<h3><a name="54"></a>54. [PDTS] Concerns with security and testability</h3>
<p><b>Section:</b> X all <b>Status:</b> <a href="active.html#NAD Future">NAD Future</a>
 <b>Submitter:</b> Google <b>Opened:</b> 2014-01-20 <b>Last modified:</b> 2014-07-05</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD Future">NAD Future</a> status.</p>
<p><b>Discussion:</b></p>
  <p>We have two primary concerns with the interface as specified: </p>
  <p>
    (a) its interface repeats the mistake of V7 Unix in 1979 by exposing access
    checking (and similarly file creation) independently from opening and mutating
    the file, and
  </p>
  <p>
    (b) it provides no realistic means of testing a software library which uses
    the standard interface for accessing the filesystem under fault scenarios.
  </p>
  <p>
    Due to the extent of (a), TOCTTOU [1] security vulnerabilities are
    guaranteed, if not during access checking[2], during other common operations
    such as temporary file creation[3].
  </p>
  <p>
    Due to (b) it is impossible to portably test libraries using the proposed
    interface against critical correctness and security edge cases.
  </p>
  <p>
    [1]: TOCTTOU: Time-of-check-to-time-of-use.&nbsp;
    <a HREF="http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5388162">Operating system integrity in OS/VS2</a>
  </p>
      <p>[2]: <a HREF="http://www.csl.sri.com/users/ddean/papers/usenix04.pdf">Fixing Races for Fun and Profit: How to use access(2)</a></p>
      <p>[3]: <a HREF="http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-10.pdf">Checking for Race Conditions in File Accesses</a></p>

  <p/>
  
  <i>[Beman Dawes: 10 Feb 2014: Suggested response: NAD, Future]</i>

  <blockquote>
    <p/>We share your concerns and look forward to receiving specific proposals to address them.
    Whether they will addressed by a revision of TS 18822 or a new TS will be decided as proposals progress
    through the committee process. See <a href="http://isocpp.org/std/submit-a-proposal">How To Submit a Proposal</a>.
  </blockquote>
  <p><i>[17 Jun 2014 Rapperswil LWG agrees NAD, Future with rationale as stated above.]</i></p>




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





<hr>
<h3><a name="59"></a>59. [PDTS] Invalid expressions for bitmask types</h3>
<p><b>Section:</b> X 10 [fs.enum] <b>Status:</b> <a href="active.html#NAD Editorial">NAD Editorial</a>
 <b>Submitter:</b> Daniel Krügler <b>Opened:</b> 2014-03-01 <b>Last modified:</b> 2014-07-05</p>
<p><b>View all issues with</b> <a href="status-index.html#NAD Editorial">NAD Editorial</a> status.</p>
<p><b>Discussion:</b></p>
<p/><code>copy_options</code> is declared as <code>enum class</code> type that is a bismask type, but the 
specification repeatedly uses expressions that are invalid for scoped 
enums, such as:

<blockquote>

<p/><code>!(options)</code>

</blockquote>

<p/>because there is no contextual conversion to bool, not even the || operator in:

<blockquote>
<p/><code>((options &amp; copy_options::recursive) || !(options)) </code>
</blockquote>

<p/>Affected are basically all formulations in the form:

<blockquote>

<p/>&quot;if <code>options &amp; copy_options::create_symlinks</code> [..]&quot;

</blockquote>

<p/>because all rely on contextual conversion to bool. The only other specifically 
mention scoped enumeration in the standard that is also a bit mask type is the 
<code>launch</code> enum and 
the wording there always uses forms such as:

<blockquote>

<p/>&quot;if <code>policy &amp; launch::deferred</code> is non-zero&quot;

</blockquote>

<p/>which better acknowledges the fact that the obtained values does not necessarily 
undergo an implicit conversion.

<p/>I think the current wording in the file system spec. must be changed, especially for 
invalid expressions of the form:

<blockquote>

<p/><code>((options &amp; copy_options::recursive) || !(options)) </code>
</blockquote>

<p/>A similar problem arises in the usage of the bitmask type <code>perms</code> for the 
expression:

<blockquote>

<p/><code>((prms &amp; add_perms) &amp;&amp; (prms &amp; remove_perms)) </code>
</blockquote>

<p/>The only way how to describe this with a scoped enum is the lengthier form

<blockquote>

<p/><code>((prms &amp; perms::add_perms) != perms::none &amp;&amp; (prms &amp; perms::remove_perms) != 
perms::none) </code>
</blockquote>

<p/>thus fixing several problems:

<ul>
  <li>The unscoped access to <code>add_perms</code> and <code>remove_perms</code> is incorrect</li>
  <li>The result of &amp; is the bitmask type again and cannot be implicitly 
  converted to bool</li>
</ul>

  <p><i>[20 May 2014 Beman Dawes provides proposed wording. Fixing invalid C++ is editorial, but treating
  this as an issue ensures more people review the proposed changes.]</i></p>


  <p><i>[17 Jun 2014 Rapperswil LWG requests issue be handled as editorial.]</i></p>




<p><b>Proposed resolution:</b></p>
  <p>
    <i>Change 15.3 Copy [fs.op.copy]:</i>
  </p>

  <blockquote>

    <blockquote>
      <p>
        Before the first use of <code>f</code> and <code>t</code>:
      </p>

      <ul>
        <li>
          If <code>
            (options &amp; copy_options::create_symlinks) <ins>
              !=
              copy_options::none
            </ins> || (options &amp; copy_options::skip_symlinks) <ins>
              !=
              copy_options::none</ins></code>, then <code>
            auto f =
            symlink_status(from)
          </code> and if needed <code>auto t = symlink_status(to)</code>.
        </li>
        <li>
          Otherwise, <code>auto f = status(from)</code> and if needed <code>
            auto
            t = status(to)
          </code>.
        </li>
      </ul>
      <p>
        Report an error as specified in
        <a href="#Error-reporting" style="color: #2020FF; text-decoration: none">Error reporting (7)</a>
        if:
      </p>

      <ul>
        <li>
          <code>!exists(f)</code>, or
        </li>
        <li>
          <code>equivalent(from, to)</code>, or
        </li>
        <li>
          <code>is_other(f) || is_other(t)</code>, or
        </li>
        <li>
          <code>is_directory(f) &amp;&amp; is_regular_file(t)</code>.
        </li>
      </ul>
      <p>
        If <code>is_symlink(f)</code>, then:
      </p>

      <ul>
        <li>
          If <code>
            <ins>(</ins>options &amp; copy_options::skip_symlinks<ins>) !=
              copy_options::none</ins></code>, then return.
        </li>
        <li>
          Otherwise if <code>!exists(t)</code>, then <code>
            copy_symlink(from,
            to, options)
          </code>.
        </li>
        <li>
          Otherwise report an error as specified in
          <a href="#Error-reporting" style="color: #2020FF; text-decoration: none">Error reporting (7)</a>.
        </li>
      </ul>
      <p>
        Otherwise if <code>is_regular_file(f)</code>, then:
      </p>

      <ul>
        <li>
          If <code>
            <ins>(</ins>options &amp; copy_options::directories_only<ins>) !=
              copy_options::none</ins></code>, then return.
        </li>
        <li>
          Otherwise if <code>
            <ins>(</ins>options &amp; copy_options::create_symlinks<ins>
              ) !=
              copy_options::none</ins></code>, then
          create a symbolic link to the source file.
        </li>
        <li>
          Otherwise if <code>
            <ins>(</ins>options &amp; copy_options::create_hard_links<ins>) !=
              copy_options::none</ins></code>,
          then create a hard link to the source file.
        </li>
        <li>
          Otherwise if <code>is_directory(t)</code>, then <code>
            copy_file(from, to/from.filename(),
            options)
          </code>.
        </li>
        <li>
          Otherwise, <code>copy_file(from, to, options)</code>.
        </li>
      </ul>
    </blockquote>
  </blockquote>
  <blockquote>
    <blockquote>
      <p>
        Otherwise if <code>
          is_directory(f) &amp;&amp; ((options &amp;
          copy_options::recursive)<ins> != copy_options::none</ins> || <del>!(</del>options <ins>
            ==
            copy_options::none</ins><del>)</del>)
        </code>
        then:
      </p>

      <ul>
        <li>
          If&nbsp; <code>!exists(t)</code>, then <code>
            create_directory(to,
            from)
          </code>.
        </li>
        <li>
          Then, iterate over the files in <code>from</code>, as if by <code>
            for
            (directory_entry&amp; x : directory_iterator(from))
          </code>, and for each
          iteration <code>
            copy(x.path(), to/x.path().filename(), options |
            copy_options::<i>unspecified</i>)
          </code>.
        </li>
      </ul>

    </blockquote>

  </blockquote>

  <p>
    <i>Change 15.4 Copy file [fs.op.copy_file]:</i>
  </p>
  <blockquote>
    <p>
      If&nbsp; <code>exists(to) &amp;&amp;</code> <code>
        <del>!</del>(options &amp; (copy_options::skip_existing
        | copy_options::overwrite_existing | copy_options::update_existing)) <ins>
          ==
          copy_options::none
        </ins>
      </code> report a
      file already exists error as specified in
      <a href="#Error-reporting" style="color: #2020FF; text-decoration: none">Error reporting (7)</a>.
    </p>
    <p>
      If <code>
        !exists(to) || (options &amp; copy_options::overwrite_existing)<ins>
          != copy_options::none
        </ins> || ((options &amp; copy_options::update_existing)<ins>
          != copy_options::none
        </ins>
        &amp;&amp; last_write_time(from) &gt; last_write_time(to)) || <del>!</del>(options &amp;
        (copy_options::skip_existing
        | copy_options::overwrite_existing | copy_options::update_existing))<ins> == copy_options::none</ins>
      </code>
      copy the contents and attributes of the file <code>from</code> resolves to
      the file <code>to</code> resolves to.
    </p>
  </blockquote>

  <p>
    <i>Change 15.26 Permissions  [fs.op.permissions]:</i>
  </p>
  <blockquote>
    <p>
      <i>Requires:</i> <code>!((prms &amp; <ins>perms::</ins>add_perms) <ins>!= perms::none</ins> &amp;&amp; (prms &amp; <ins>perms::</ins>remove_perms) <ins>!= perms::none</ins>)</code>.
    </p>
  </blockquote>






<hr>
<h3><a name="61"></a>61. Surprising <tt>equivalent()</tt> behavior if neither file exists</h3>
<p><b>Section:</b> X 6 [fs.filesystem.synopsis] <b>Status:</b> <a href="active.html#NAD">NAD</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2014-04-12 <b>Last modified:</b> 2014-07-05</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>
  <code>
    bool equivalent(const path&amp; p1, const path&amp; p2);
  </code> has always thrown a exception if neither file exists,
   with rationale that if they don't exist, it isn't possible to tell
   if two paths are equivalent. Dave Abrahams has reported that this
   is counter-intuitive and hard to teach.
</p>
  <p>An alternative if neither path exists would be to return true
  if they are lexically equal (operator==), otherwise return false.</p>
  <p>This was not a national body comment, and Dave is the only one
  I can recall ever complaining about the current behavior. On the
  other hand, any complaint from Dave deserves serious consideration.</p>

  <p><i>[17 Jun 2014 Rapperswil LWG considers this NAD. Mixing lexical and existence based
  behavior is not desirable.]</i></p>





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





</body>
</html>
