https://svn.boost.org/trac10/ticket/7607 <p> Currently, a path that ends with a slash (or backslash on Windows) is treated as if it had an invisible "." at the end. For example, filename("/usr/") returns ".", and iterating over path("/usr/") produces the elements "/", "usr", and ".". </p> <p> I think this is a design error, because it leads to unexpected behaviors. For example, create_directories("foo/") fails even though the directory "foo" is successfully created, because the code tries to conclude by creating ".", which makes no sense and obviously will fail. </p> <p> I think the effect of ending a path with a slash should simply be that the final element (preceding the slash) is considered a directory name, not a filename. Therefore filename("foo/") should return an empty string, and has_filename("foo/") should return false. Most other operations, however, should act as if the slash simply wasn't there. Iterating over path("/usr/bin/"), for example, should return the elements "/", "usr", and "bin", and create_directories("foo/") should behave exactly the same as create_directories("foo"). </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7607 Trac 1.4.3 Beman Dawes Thu, 03 Sep 2015 19:35:38 GMT https://svn.boost.org/trac10/ticket/7607#comment:1 https://svn.boost.org/trac10/ticket/7607#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> The behavior of path iteration is as intended. The C++ Standard Library's File System TS specifies the same behavior. A note supplying rationale has been added to the reference documentation for path iteration as part of the resolution of ticket <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/10766" title="#10766: Bugs: boost::filesystem::path::parent_path() with redundant separator ... (closed: fixed)">#10766</a>; See section [path.itr]. </p> <p> The issue of create_directories("foo/") and several related problems with ".." and "." elements in calls to create_directories() have been fixed by ticket <a class="reopened ticket" href="https://svn.boost.org/trac10/ticket/7258" title="#7258: Bugs: boost::filesystem::create_directories(const &amp;path) returns false if ... (reopened)">#7258</a>, and results for create_directories() should now be as you requested. </p> <p> Based on the title, this issue is being closed as "wontfix". If you are unhappy with this, you might want to submit an issue to the C++ committee's Library Working Group. The rationale for keeping the implicit '.' semantics is week enough that the LWG might be willing to change the spec before Filesystem gets into the actual C++ Standard itself. </p> <p> Thanks, </p> <p> --Beman </p> Ticket