Opened 10 years ago
Closed 7 years ago
#7607 closed Bugs (wontfix)
path should not infer an invisible "." at the end of a path that ends with a slash
| Reported by: | Owned by: | Beman Dawes | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | filesystem |
| Version: | Boost 1.50.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
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 ".".
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.
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").
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 #10766; See section [path.itr].
The issue of create_directories("foo/") and several related problems with ".." and "." elements in calls to create_directories() have been fixed by ticket #7258, and results for create_directories() should now be as you requested.
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.
Thanks,
--Beman