Document number: N3365=12-0055
Date: 2012-02-27
Project: Programming Language C++, Library Working Group
Reply-to: Beman Dawes <bdawes at acm dot org>

Filesystem Library Proposal (Revision 2)

This paper proposes a filesystem library component suitable for a C++ Standard Library Technical Report or for the C++ Standard Library. The proposed library is based on Version 3 of the Boost Filesystem Library (see www.boost.org/libs/filesystem). Preliminary wording is provided. A TODO list identifies remaining work to be done.

Revision history

N3365=12-0055, Filesystem Library Proposal (Revision 2). Changes include:

N3335=12-0025, Filesystem Library for C++11/TR2 (Revision 1). Changes include:

N3239 = 11-0009, Filesystem Library Update for TR2 (Preliminary), reflected changes made to the Boost library version 3 since the previously accepted committee paper:

N1975 = 06-0045, Filesystem Library Proposal for TR2 (Revision 3), was adopted by the committee in April, 2006, at the Berlin meeting. Shortly afterward the Library Working Group set aside work on TR2 to concentrate on C++0x.

Motivation and Scope

The motivation and scope for a filesystem library were described in N1975, and are not repeated here. A minor scope reduction is that an addition to the current C++ runtime library is no longer needed.

Boost Filesystem Version 3 introduced a single path type that interoperates well with both basic_string and user defined string types. Thus the following Design alternatives paragraph is no long applicable:

Single path type which can at runtime accept narrow or wide character pathnames. Although certainly interesting, and possibly superior, such a design would not interoperate well with the current Standard Library's compile-time typed basic_string. A new runtime polymorphic string class would be the best place to experiment with this concept, not a path class.

TODO

Table of Contents

Introduction
Definitions
Conformance
Header <filesystem> synopsis
Error reporting
Class path
    path conversions
    path conversions to native format
    path conversions to generic format
    path encoding conversions
    path requirements
    path constructors
    path assignments
    path appends
    path modifiers
    path native format observers
    path generic format observers
    path decomposition
    path query
    path iterators
    path non-member functions
    path inserters and extractors
 Class filesystem_error
    filesystem_error constructors
    filesystem_error path1
    filesystem_error path2
    filesystem_error what
Enum file_type
Enum perms
Class file_status
    file_status constructors
    file_status-modifiers observers
    file_status-observers modifiers
Class directory_entry
    directory_entry constructors
    directory_entry observers
    directory_entry modifiers
Class directory_iterator
    directory_iterator members
Class recursive_directory_iterator
Operational functions
     absolute
     canonical
     copy
     copy_directory
     copy_file
     copy_symlink
     create_directories
     create_directory
     create_hard_link
     create_symlink
     current_path
     exists
     equivalent
     file_size
     hard_link_count
     initial_path
     is_directory
     is_empty
     is_other
     is_regular_file
     is_symlink
     last_write_time
     permissions
     read_symlink
     remove
     remove_all
     rename
     resize_file
     space
     status
     status_known
     symlink_status
     system_complete
     temp_directory_path
    
unique_path
File streams
Path decomposition table
Warning: Long paths on Windows and the extended-length \\?\ prefix
Acknowledgements
References
 

Proposed Wording

Gray-shaded italic text is commentary on the proposal. It is not to be added to the TR.

Add the following to the Technical Report's front matter:

The following standard contains provisions which, through reference in this text, constitute provisions of this Technical Report. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Technical Report are encouraged to investigate the possibility of applying the most recent editions of the standard indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.

ISO/IEC 9945:2003, with the indicated corrections, is hereinafter called POSIX.

Footnote 1: POSIX® is a registered trademark of The IEEE.

Footnote 2: UNIX® is a registered trademark of The Open Group.

Add the following to the Technical Report as a new Clause:

Filesystem Library

This Clause describes components that perform operations on file systems and their components, such as paths, regular files, and directories.

Operating systems such as Linux, MAC OS, UNIX, and Windows are mentioned in this Clause for purposes of illustration or to give guidance to implementers. No slight to other operating systems is implied or intended.

Footnote: Linux® is a registered trademark of Linus Torvalds.

Footnote: MAC OS® is a registered trademark of Apple Inc.

Footnote: UNIX® is a registered trademark of The Open Group.

Footnote: Windows® is a registered trademark of Microsoft Corporation.

Conformance

Behavior is sometimes specified by reference to ISO/IEC 9945:2003, POSIX. How such behavior is actually implemented is unspecified.

[Note: This constitutes an "as if" rule for implementation of operating system dependent behavior. Presumably implementations will usually call native operating system API's. --end note]

Implementations are encouraged, but not required, to support such behavior as it is defined by POSIX. Implementations shall document any behavior that differs from the POSIX defined behavior. Implementations that do not support exact POSIX behavior are encouraged to provide behavior as close to POSIX behavior as is reasonable given the limitations of actual operating systems and file systems. If an implementation cannot provide any reasonable behavior, the implementation shall report an error in an implementation-defined manner.

[Note: Such errors might be reported by an #error directive, a static_assert, a filesystem_error exception, a special return value, or some other manner. --end note]

Implementations are not required to provide behavior that is not supported by a particular file system.

[Example: The FAT file system used by some memory cards, camera memory, and floppy discs does not support hard links, symlinks, and many other features of more capable file systems. Implementations are only required to support the FAT features supported by the host operating system. -- end example]

Specific operating systems such as OpenVMS, UNIX, and Windows are mentioned only for purposes of illustration or to give guidance to users and implementers. No slight to other operating systems is implied or intended. When unlikely to cause confusion, the term POSIX is sometimes used to refer to "POSIX-compliant operating systems".

The behavior of functions described in this reference may differ from their specification in the presence of file system races. No diagnostic is required.

If the possibility of a file system race would make it unreliable for a program to test for a precondition before calling a function described in this Clause, Requires is not specified for the condition. Instead, the condition is specified as a Throws condition.

[Note: As a design practice, preconditions are not specified when it is unreasonable for a program to detect them prior to calling the function. -- end note]

Definitions

The following definitions shall apply throughout this reference documentation:

File: An object that can be written to, or read from, or both. A file has certain attributes, including type. File types include regular files and directories. Other types of files, such as symbolic links, may be supported by the implementation.

File system: A collection of files and certain of their attributes.

Filename: The name of a file. Slash and 0x00 characters are not permitted. Implementations may define additional characters or specific names that are not permitted. Filenames .  and ..  have special meaning. Implementations may define additional filenames that have special meaning.

[Note: Most operating systems prohibit the ASCII control characters (0x00-0x1F) in filenames.

Windows prohibits the characters 0x00-0x1F, ", *, :, <, >, ?, \, /, and | --end note]

Path: A sequence of elements that identify the location of a file within a filesystem. The elements are the root-nameopt, root-directoryopt, and an optional sequence of filenames. [Note: A pathname is the concrete representation of a path. --end note]

Absolute path: A path that unambiguously identifies the location of a file within a file system without reference to an additional starting location. The format is implementation defined.

[Note: For POSIX-like implementations, including Unix variants, Linux, and Mac OS X, only paths that begin with a slash are absolute paths.

For Windows-like implementations, including Cygwin and MinGW, only paths that begin with a drive specifier followed by a slash, or begin with two slashes, are absolute paths. --end note]

Relative path: A path that only unambiguously identifies the location of a file within a filesystem when resolved relative to a starting location. The format is implementation defined. [Note: Paths "." and ".." are considered to be relative paths. --end note]

Canonical path: An absolute path that has no elements which are symbolic links, and no dot or dot dot elements.

Pathname: A character string that represents a path. Pathnames are formatted according to the generic pathname format or an implementation defined native pathname format.

Generic pathname format:

pathname:
            root-nameopt root-directoryopt relative-pathopt

root-name:
            implementation-defined

[Note: Most POSIX and Windows based operating systems define a name beginning with two slashes (or backslashes, for Windows) as a root-name identifying network locations. Windows defines a single letter followed by a ":" as a root-name identifying a disc drive. --end note]

root-directory:
            directory-separator

relative-path:
            filename
            relative-path directory-separator
            relative-path directory-separator filename

filename:
            name
           
"."
           
".."

directory-separator:
            "/"
      "/"
directory-separator

Multiple successive directory-separator characters are considered to be the same as one directory-separator character. The filename "." is considered to be a reference to the current directory. The filename ".." is considered to be a reference to the current directory. Specific filenames may have special meaning for a particular operating system.

Native pathname format:  An implementation defined format. [Note: For POSIX-like operating systems, the native format is the same as the generic format. For Windows, the native format is similar to the generic format, but the directory-separator characters can be either slashes or backslashes. --end note]

Link: A directory entry object that associates a filename with a file. On some file systems, several directory entries can associate names with the same file.

Hard link: A link to an existing file. Some file systems support multiple hard links to a file. If the last hard link to a file is removed, the file itself is removed.

[Note: A hard link can be thought of as a shared-ownership smart pointer to a file. -- end note]

Symbolic link: A type of file with the property that when the file is encountered during pathname resolution, a string stored by the file is used to modify the pathname resolution.

[Note: A symbolic link can be thought of as a raw pointer to a file. If the file pointed to does not exist, the symbolic link is said to be a "dangling" symbolic link. -- end note]

File system race: The condition that occurs when multiple threads, processes, or computers interleave access and modification of the same object within a file system.

Dot, Dot Dot: Synonyms for the filenames "." and "..", respectively. The dot filename names the current directory. The dot dot filename names the parent directory.

Header <filesystem> synopsis

namespace std { namespace tbd { namespace filesystem {

    class path;

    void swap(path& lhs, path& rhs);
    bool lexicographical_compare(path::iterator first1, path::iterator last1,
                                 path::iterator first2, path::iterator last2);
    std::size_t hash_value(const path& p);

    bool operator==(const path& lhs, const path& rhs);
    bool operator!=(const path& lhs, const path& rhs);
    bool operator< (const path& lhs, const path& rhs);
    bool operator<=(const path& lhs, const path& rhs);
    bool operator> (const path& lhs, const path& rhs);
    bool operator>=(const path& lhs, const path& rhs);

    path operator/ (const path& lhs, const path& rhs);

    std::ostream&  operator<<( std::ostream& os, const path& p );
    std::wostream& operator<<( std::wostream& os, const path& p );
    std::istream&  operator>>( std::istream& is, path& p );
    std::wistream& operator>>( std::wistream& is, path& p )

    class filesystem_error;      
    class directory_entry;

    class directory_iterator;

    class recursive_directory_iterator;

    enum file_type
    {
      status_error, file_not_found, regular_file, directory_file,
      symlink_file, block_file, character_file, fifo_file, socket_file,
      type_unknown
    };

    enum perms
    {
      no_perms,
      owner_read, owner_write, owner_exe, owner_all,
      group_read, group_write, group_exe, group_all,
      others_read, others_write, others_exe, others_all, all_all,
      set_uid_on_exe, set_gid_on_exe, sticky_bit,
      perms_mask, perms_not_known,
      add_perms, remove_perms, symlink_perms
    };

    class file_status;

    struct space_info  // returned by space function
    {
      uintmax_t capacity;
      uintmax_t free; 
      uintmax_t available; // free space available to a non-privileged process
    };

    enum class copy_option
    {
      none
      fail_if_exists = none,
      overwrite_if_exists
    };

    enum class symlink_option
    {
      none
      no_recurse = none,
      recurse
    };

    // operational functions

    path         absolute(const path& p, const path& base=current_path());

    path         canonical(const path& p, const path& base = current_path());
    path         canonical(const path& p, system::error_code& ec);
    path         canonical(const path& p, const path& base, system::error_code& ec);

    void         copy(const path& from, const path& to);
    void         copy(const path& from, const path& to, system::error_code& ec);

    void         copy_directory(const path& from, const path& to);
    void         copy_directory(const path& from, const path& to, system::error_code& ec);

    void         copy_file(const path& from, const path& to);
    void         copy_file(const path& from, const path& to, system::error_code& ec);
    void         copy_file(const path& from, const path& to, copy_option option);
    void         copy_file(const path& from, const path& to, copy_option option,
                           system::error_code& ec);

    void         copy_symlink(const path& existing_symlink, const path& new_symlink);
    void         copy_symlink(const path& existing_symlink, const path& new_symlink, system::error_code& ec);

    bool         create_directories(const path& p);
    bool         create_directories(const path& p, system::error_code& ec);

    bool         create_directory(const path& p);
    bool         create_directory(const path& p, system::error_code& ec);

    void         create_directory_symlink(const path& to, const path& new_symlink);
    void         create_directory_symlink(const path& to, const path& new_symlink, system::error_code& ec);

    void         create_hard_link(const path& to, const path& new_hard_link);
    void         create_hard_link(const path& to, const path& new_hard_link, system::error_code& ec);

    void         create_symlink(const path& to, const path& new_symlink);
    void         create_symlink(const path& to, const path& new_symlink, system::error_code& ec);

    path         current_path();
    path         current_path(system::error_code& ec);
    void         current_path(const path& p);
    void         current_path(const path& p, system::error_code& ec);

    bool         exists(file_status s) noexcept;
    bool         exists(const path& p);
    bool         exists(const path& p, system::error_code& ec) noexcept;

    bool         equivalent(const path& p1, const path& p2);
    bool         equivalent(const path& p1, const path& p2, system::error_code& ec);

    uintmax_t    file_size(const path& p);
    uintmax_t    file_size(const path& p, system::error_code& ec);

    uintmax_t    hard_link_count(const path& p);
    uintmax_t    hard_link_count(const path& p, system::error_code& ec);

    const path&  initial_path();
    const path&  initial_path(system::error_code& ec);

    bool         is_directory(file_status s) noexcept;
    bool         is_directory(const path& p);
    bool         is_directory(const path& p, system::error_code& ec) noexcept;

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

    bool         is_other(file_status s) noexcept;
    bool         is_other(const path& p,);
    bool         is_other(const path& p, system::error_code& ec) noexcept;

    bool         is_regular_file(file_status s) noexcept; 
    bool         is_regular_file(const path& p);
    bool         is_regular_file(const path& p, system::error_code& ec) noexcept;

    bool         is_symlink(file_status s noexcept);
    bool         is_symlink(const path& p);
    bool         is_symlink(const path& p, system::error_code& ec) noexcept;

    std::time_t  last_write_time(const path& p);
    std::time_t  last_write_time(const path& p, system::error_code& ec);
    void         last_write_time(const path& p, const std::time_t new_time);
    void         last_write_time(const path& p, const std::time_t new_time, system::error_code& ec);

    path         read_symlink(const path& p);
    path         read_symlink(const path& p, system::error_code& ec);

    bool         remove(const path& p);
    bool         remove(const path& p, system::error_code& ec);

    uintmax_t    remove_all(const path& p);
    uintmax_t    remove_all(const path& p, system::error_code& ec);

    void         rename(const path& from, const path& to);
    void         rename(const path& from, const path& to, system::error_code& ec);

    void         resize_file(const path& p, uintmax_t size);
    void         resize_file(const path& p, uintmax_t size, system::error_code& ec);

    space_info   space(const path& p);
    space_info   space(const path& p, system::error_code& ec);

    file_status  status(const path& p);
    file_status  status(const path& p, system::error_code& ec) noexcept;

    bool         status_known(file_status s) noexcept;

    file_status  symlink_status(const path& p);
    file_status  symlink_status(const path& p, system::error_code& ec) noexcept;

    path         system_complete(const path& p);
    path         system_complete(const path& p, system::error_code& ec);

    path         temp_directory_path();
    path         temp_directory_path(system::error_code& ec);

    path         unique_path(const path& model="%%%%-%%%%-%%%%-%%%%");
    path         unique_path(const path& model, system::error_code& ec);

} } }  // namespaces std::tbd::filesystem

Error reporting

Filesystem library functions often provide two overloads, one that throws an exception to report file system errors, and another that sets an error_code.

[Note: This supports two common use cases:

--end note]

Functions not having an argument of type system::error_code& report errors as follows, unless otherwise specified:

Functions having an argument of type system::error_code& report errors as follows, unless otherwise specified:

Class path

An object of class path represents a path, and contains a pathname Such an object is concerned only with the lexical and syntactic aspects of a path. The path does not necessarily exist in external storage, and the pathname is not necessarily valid for the current operating system or for a particular file system.

[Example: A long path name on Windows is an example of an innocuous appearing path that is not actually valid. -- end example]

namespace std { namespace tbd { namespace filesystem {

      class path
      {
      public:
        typedef see below                                    value_type;  // char for POSIX, wchar_t for Windows
        typedef std::basic_string<value_type>                string_type;
        typedef std::codecvt<wchar_t, char, std::mbstate_t>  codecvt_type;

        // constructors and destructor
        path();
        path(const path& p);
        path(path&& p) noexcept;

        template <class Source>
          path(Source const& source, const codecvt_type& cvt=codecvt());

        template <class InputIterator>
          path(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

       ~path();

        // assignments
        path& operator=(const path& p);
        path& operator=(path&& p) noexcept;

        template <class Source>
          path& operator=(Source const& source);

        template <class Source>
          path& assign(Source const& source, const codecvt_type& cvt)

        template <class InputIterator>
          path& assign(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

        // appends
        path& operator/=(const path& p);

        template <class Source>
          path& operator/=(Source const& source);

        template <class Source>
          path& append(Source const& source, const codecvt_type& cvt);

        template <class InputIterator>
          path& append(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

        // modifiers
        void  clear();
        path& make_absolute(const path& base);
        path& make_preferred();  // POSIX: no effect. Windows: convert slashes to backslashes
        path& remove_filename();
        path& replace_extension(const path& new_extension = path());
        void  swap(path& rhs);

        // native format observers
        const string_type&  native() const noexcept;  // native format, encoding
        const value_type*   c_str() const noexcept;   // native().c_str()

        template <class String>
        String string(const codecvt_type& cvt=codecvt()) const;                // native format

        const string        string(const codecvt_type& cvt=codecvt()) const;   // native format
        const wstring       wstring(const codecvt_type& cvt=codecvt()) const;  // ditto
        const u16string     u16string() const;                                 // ditto
        const u32string     u32string() const;                                 // ditto

        // generic format observers
        template <class String>
        String generic_string() const;

        const string        generic_string(const codecvt_type& cvt=codecvt()) const;   // generic format
        const wstring       generic_wstring(const codecvt_type& cvt=codecvt()) const;  // ditto
        const u16string     generic_u16string() const;                                 // ditto
        const u32string     generic_u32string() const;                                 // ditto

        // decomposition
        path  root_name() const;
        path  root_directory() const;
        path  root_path() const;
        path  relative_path() const;
        path  parent_path() const;
        path  filename() const;
        path  stem() const;
        path  extension() const;

        // query
        bool empty() const;
        bool has_root_name() const;
        bool has_root_directory() const;
        bool has_root_path() const;
        bool has_relative_path() const;
        bool has_parent_path() const;
        bool has_filename() const;
        bool has_stem() const;
        bool has_extension() const;
        bool is_absolute() const;
        bool is_relative() const;

        // iterators
        class iterator;
        typedef iterator const_iterator;

        iterator begin() const;
        iterator end() const;
        
        // encoding conversion
        static std::locale imbue( const std::locale& loc );
        static const codecvt_type & codecvt();

      private:
        string_type pathname;  // exposition only
      };

} } }  // namespaces std::tbd::filesystem

value_type is an implementation-defined typedef for the character type used by the operating system to represent pathnames.

Member functions described as returning const string, const wstring, const u16string, or const u32string are permitted to return const string&, const wstring&, const u16string&, or const u32string&, respectively.

[Note: This allows implementations to avoid unnecessary copies when no conversion is required. Return-by-value is specified as const to ensure programs won't break if moved to a return-by-reference implementation. -- end note]

path Conversions

path Conversions to native format

Member function arguments that take character sequences representing paths may use the generic pathname format or the native pathname format. If such an argument uses the generic format, an implementation defined conversion to native format is performed during the processing of the argument.

[Note: No conversion occurs on POSIX and Windows since they have native formats that conform to the generic format. --end note]

[Rationale: There is no unambiguous way for an implementation to always be able distinguish between native format and generic format arguments. This is by design as it simplifies use. Should an implementation encounter an operating system where disambiguation is required, an implementation defined native format prefix can be introduced to identify the native format. -- end rationale]

Class path does not currently map invalid characters in filenames to valid characters. In the future we might add something like this:

When converting filenames to the native operating system format, implementations are encouraged, but not required, to convert otherwise invalid characters or character sequences to valid characters or character sequences. Such conversions are implementation-defined.

[Note: Filename conversion allows much wider portability of both programs and filenames that would otherwise be possible.

Implementations are encouraged to base conversion on existing standards or practice. Examples include the Uniform Resource Locator escape syntax of a percent sign ('%') followed by two hex digits representing the character value. On OpenVMS, which does not allow percent signs in filenames, a dollar sign ('$') followed by two hex digits is the existing practice, as is converting lowercase letters to uppercase. -- end note.]

If the native format requires paths for regular files to be formatted differently from paths for directories, the path shall be treated as a directory path if last element is a separator, otherwise it shall be treated as a regular file path.

[Note: The above paragraph does not apply to POSIX and Windows since they use the same format for both regular file and directory pathnames. --end note]

[Example: On OpenVMS, a path constructed from "/cats/jane" would considered a regular file path, and have a native format of "[CATS]JANE", while a path constructed from "/cats/jane/" would be considered a directory path, and have a native format of "[CATS.JANE]". --end example]

path Conversions to generic format

Generic format observer functions return strings formatted according to the generic pathname format. The conversion from generic to native formats is implementation defined.

[Note: For POSIX, no conversion is performed. For Windows, backslashes are converted to forward slashes. -- end note]

path Encoding conversions

If the value type of member function arguments that are character sequences representing paths is not value_type, and no cvt argument is supplied, conversion to value_type occurs using an imbued locale. This imbued locale is initialized with a codecvt facet appropriate for the operating system.

For Apple OS X implementations, path::value_type is char. The default imbued locale provides a UTF-8 codecvt facet. [Rationale: "All BSD system functions expect their string parameters to be in UTF-8 encoding and nothing else." See Apple docs. -- end rationale]

For Windows-like implementations, including MinGW, path::value_type is wchar_t. The default imbued locale provides a codecvt facet that invokes Windows MultiByteToWideChar or WideCharToMultiByte API with a codepage of CP_THREAD_ACP if Windows AreFileApisANSI()is true, otherwise codepage CP_OEMCP. [Rationale: this is the current behavior of C and C++ programs that perform file operations using narrow character string to identify paths. Changing this in the Filesystem library would be too surprising, particularly where user input is involved. -- end rationale]

For all other implementations, including Linux, path::value_type is char. The default imbued locale is std::locale(""). [Rationale: ISO C specifies this as "the locale-specific native environment", while POSIX says it "Specifies an implementation-defined native environment." -- end rationale]

path Requirements

Template parameters named InputIterator are required meet the requirements for a C++ standard library RandomIterator compliant iterator. The iterator's value type is required to be char, wchar_t, char16_t, or char32_t.

Template parameters named Source are required to be one of:

path constructors

path();

Postcondition: empty().

template <class Source>
  path(Source const& source, const codecvt_type& cvt=codecvt());
template <class InputIterator>
  path(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

Effects: Stores the contents [begin,end) or source in pathname. If the contents are in the generic format and the generic format is unacceptable to the operating system's API, they are converted to the native format. [Note: For POSIX and Windows implementations, the generic format is already acceptable as a native format, so no generic to native conversion is performed. --end note]

Remarks: If the value type of  [begin,end) or source is not value_type, conversion is performed by cvt.

path assignments

template <class Source>
  path& operator=(Source const& source);
template <class Source>
  path& assign(Source const& source, const codecvt_type& cvt);
template <class InputIterator>
  path& assign(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

Effects: Stores the contents [begin,end) or source in pathname. If the contents are in the generic format, they are converted to the native format. [Note: For POSIX and Windows based implementations, the generic format is already acceptable as a native format, so no generic to native conversion is performed. --end note]

Returns: *this

Remarks: If the value type of  [begin,end) or source is not value_type, conversion is performed by cvt.

path appends

The append operations use operator/= to denote their semantic effect of appending the platform's preferred directory separator when needed. The preferred directory separator is implementation-defined.

[Note: For POSIX-like implementations, including Unix variants, Linux, and Mac OS X, the preferred directory separator is a single forward slash.

For Windows-like implementations, including Cygwin and MinGW, the preferred directory separator is a single backslash.--end note]

path& operator/=(const path& p);

Effects:

Appends the preferred directory separator to the contained pathname, unless:

Appends p.native() to pathname.

Returns: *this

template <class Source>
  path& operator/=(Source const & source);
template <class Source>
  path& append(Source const & source, const codecvt_type& cvt);
template <class InputIterator>
  path& append(InputIterator begin, InputIterator end, const codecvt_type& cvt=codecvt());

Effects:

Appends a native directory separator to the contained pathname, unless:

Appends the contents [begin,end) or source to pathname. If the contents are in the generic format, they are converted to the native format. [Note: For POSIX and Windows based implementations, the generic format is already acceptable as a native format, so no generic to native conversion is performed. --end note]

Remarks: If the value type of  [begin,end) or source is not value_type, conversion is performed by cvt.

Returns: *this

path modifiers

void clear();

Postcondition: this->empty() is true.

path& make_preferred();

Effects: The contained pathname is converted to the preferred native format. [Note: On Windows, the effect is to replace slashes with backslashes. On POSIX, there is no effect. -- end note]

Returns: *this

path& remove_filename();

Returns: As if, *this = parent_path();

[Note: This function is needed to efficiently implement directory_iterator. It is exposed to allow additional uses. The actual implementation may be much more efficient than *this = parent_path()  -- end note]

path& replace_extension(const path& new_extension = path());

Postcondition: extension() == replacement, where replacement is new_extension if new_extension.empty() || new_extension[0] == the dot character, otherwise replacement is the dot character followed by new_extension.

Returns: *this

void swap(path& rhs) noexcept;

Effects: Swaps the contents of the two paths.

Complexity: constant time.

path native format observers

The string returned by all native format observers is in the native pathname format.

const string_type&  native() const noexcept;

Returns: pathname.

const value_type* c_str() const noexcept;

Returns: pathname.c_str().

template <class String>
String string(const codecvt_type& cvt=codecvt()) const;

Returns: pathname.

Remarks: If string_type is a different type than String, conversion is performed by cvt.

const string string(const codecvt_type& cvt=codecvt()) const;
const wstring wstring(const codecvt_type& cvt=codecvt()) const;
const u16string u16string() const;
const u32wstring u32wstring() const; 

Returns: pathname.

Remarks: If string_type is a different type than function's return type, conversion is performed by cvt.

If string_type is the same type as the function's return type, the function is permitted to return by const& rather than const value. [Note: For POSIX, this occurs for string(), for Windows, wstring(). --end note]

path generic format observers

The string returned by all generic format observers is in the generic pathname format.

[Note: For POSIX, no conversion occurs, since the native format and generic format are the same. For Windows, backslashes are converted to slashes --end note]

template <class String>
String generic_string(const codecvt_type& cvt=codecvt()) const;

Returns: pathname.

Remarks: If string_type is a different type than String, conversion is performed by cvt.

const string generic_string(const codecvt_type& cvt=codecvt()) const;
const wstring generic_wstring(const codecvt_type& cvt=codecvt()) const;
const u16string generic_u16string() const;
const u32wstring generic_u32wstring() const; 

Returns: pathname.

Remarks:  If string_type is a different type than function's return type, conversion is performed by cvt.

If string_type is of the same type as the function's return type, and the generic format is the same as the native format, the function is permitted to return by const& rather than const value. [Note: For POSIX, this occurs for string(). It never occurs for Windows, because backslashes must be converted to slashes. --end note]

path decomposition

See the Path decomposition table for examples for values returned by decomposition functions. The Tutorial may also be helpful.

path root_name() const;

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

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.

path root_path() const;

Returns: root_name() / root_directory()

path relative_path() const;

Returns: A path composed from pathname, if !empty(), beginning with the first filename after root-path. Otherwise, path().

path parent_path() const;

Returns: (empty() || begin() == --end()) ? path() : pp, where pp is constructed as if by starting with an empty path and successively applying operator/= for each element in the range begin(), --end().

path filename() const;

Returns: empty() ? path() : *--end()

[Example:

std::cout << path("/foo/bar.txt").filename(); // outputs "bar.txt"

--end example]

path stem(const path& p) const;

Returns: if p.filename()contains a dot but does not consist solely of one or to two dots, returns the substring of p.filename() starting at its beginning and ending at the last dot (the dot is not included). Otherwise, returns p.filename().

[Example:

std::cout << path("/foo/bar.txt").stem(); // outputs "bar"
path p = "foo.bar.baz.tar";
for (; !p.extension().empty(); p = p.stem())
  std::cout << p.extension() << '\n';
  // outputs: .tar
  //          .baz
  //          .bar

--end example]

path extension(const path& p) const;

Returns: if p.filename() contains a dot but does not consist solely of one or to two dots, returns the substring of p.filename() starting at the rightmost dot and ending at the path's end. Otherwise, returns an empty path object.

Remarks: Implementations are permitted but not required to define additional behavior for file systems which append additional elements to extensions, such as alternate data streams or partitioned dataset names.

[Example:

std::cout << path("/foo/bar.txt").extension(); // outputs ".txt"

--end example]

[Note: The dot is included in the return value so that it is possible to distinguish between no extension and an empty extension. See http://permalink.gmane.org/gmane.comp.lib.boost.devel/199744 for more extensive rationale.  -- end note]

path query

bool empty() const;

Returns: m_pathname.empty().

bool has_root_path() const;

Returns: !root_path().empty()

bool has_root_name() const;

Returns: !root_name().empty()

bool has_root_directory() const;

Returns: !root_directory().empty()

bool has_relative_path() const;

Returns: !relative_path().empty()

bool has_parent_path() const;

Returns: !parent_path().empty()

bool has_filename() const;

Returns: !filename().empty()

bool has_stem() const;

Returns: !stem().empty()

bool has_extension() const;

Returns: !extension().empty()

bool is_absolute() const;

Returns: true if the elements of root_path() uniquely identify a directory, else false.

[Note: On POSIX, path("/foo").is_absolute() returns true. On Windows, path("/foo").is_absolute() returns false. --end note]

bool is_relative() const;

Returns: !is_absolute().

path iterators

A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (C++ Std, 24.1.4 Bidirectional iterators [lib.bidirectional.iterators]). Its value_type is path.

Calling any non-const member function of a path object invalidates all iterators referring to elements of that object.

The forward traversal order is as follows:

The backward traversal order is the reverse of forward traversal.

iterator begin() const;

Returns: An iterator for the first present element in the traversal list above. If no elements are present, the end iterator.

iterator end() const;

Returns: The end iterator.

path encoding conversion

static std::locale imbue(const std::locale& loc);

Effects: Stores loc as the default locale for all objects of type path.

Returns: The previous default locale for all objects of type path.

static const codecvt_type& codecvt();

Returns: The codecvt facet for the default locale for all objects of type path.

path non-member functions

void swap( path& lhs, path& rhs )

Effects: lhs.swap(rhs).

bool lexicographical_compare(path::iterator first1, path::iterator last1,
                             path::iterator first2, path::iterator last2)

Returns: true if the sequence of native() strings for the elements defined by the range [first1,last1) is lexicographically less than the sequence of native() strings for the elements defined by the range [first2,last2). Returns false otherwise.

Remarks: If two sequences have the same number of elements and their corresponding elements are equivalent, then neither sequence is lexicographically less than the other. If one sequence is a prefix of the other, then the shorter sequence is lexicographically less than the longer sequence. Otherwise, the lexicographical comparison of the sequences yields the same result as the comparison of the first corresponding pair of elements that are not equivalent.

  for ( ; first1 != last1 && first2 != last2 ; ++first1, ++first2) {
    if (first1->native() < first2->native()) return true;
    if (first2->native() < first1->native()) return false;
  }
  return first1 == last1 && first2 != last2;

[Note: A path aware lexicographical_compare is provided to avoid infinite recursion in std::lexicographical_compare due to the path iterator's value type itself being path. --end note]

std::size_t hash_value (const path& p);

Returns: A hash value for the path p. If for two paths, p1 == p2 then hash_value(p1) == hash_value(p2).

This allows paths to be used with Boost.Hash.

bool operator< (const path& lhs, const path& rhs);

Returns: return lexicographical_compare(lhs.begin(), lhs.end(), rhs.begin(), rhs.end()).

bool operator<=(const path& lhs, const path& rhs);

Returns: !(rhs < lhs).

bool operator> (const path& lhs, const path& rhs);

Returns: rhs < lhs.

bool operator>=(const path& lhs, const path& rhs);

Returns: !(lhs < rhs).

bool operator==(const path& lhs, const path& rhs);

Returns: !(lhs < rhs) && !(rhs < lhs).

[Note: Actual implementations may use an equivalent, but more efficient, algorithm. --end note]

[Note: Path equality and path equivalence have different semantics.

Equality is determined by the path non-member operator==, which considers the two path's lexical representations only. Thus path("foo") == "bar" is never true.

Equivalence is determined by the equivalent() non-member function, which determines if two paths resolve to the same file system entity. Thus equivalent("foo", "bar") will be true when both paths resolve to the same file.

Programmers wishing to determine if two paths are "the same" must decide if "the same" means "the same representation" or "resolve to the same actual file", and choose the appropriate function accordingly. -- end note]

bool operator!=(const path& lhs, const path& rhs);

Returns: !(lhs == rhs).

path operator/ (const path& lhs, const path& rhs);

Returns: path(lhs) /= rhs.

path inserter and extractor

The inserter and extractor delimit the string with double-quotes (") to ensure that paths with embedded spaces will round trip correctly. Ampersand (&) is used as an escape character, so the path can itself contain double quotes.

template <class Char, class Traits>
std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& os,
                                             const path& p)

Effects:  os << boost::io::quoted(p.string<std::basic_string<Char>>(), static_cast<Char>('&'));

Returns: os

template <class Char, class Traits>
inline std::basic_istream<Char, Traits>& operator>>(std::basic_istream<Char, Traits>& is,
                                                    path& p)

Effects:   std::basic_string<Char> str;
        is >> boost::io::quoted(str, static_cast<Char>('&'));
        p = str;

Returns: is

Class filesystem_error

namespace std { namespace tbd { namespace filesystem {

      class filesystem_error : public system_error
      {
      public:
        filesystem_error();
        filesystem_error(const filesystem_error&);
        filesystem_error(const std::string& what_arg,
          system::error_code ec);
        filesystem_error(const std::string& what_arg,
          const path& p1, system::error_code ec);
        filesystem_error(const std::string& what_arg,
          const path& p1, const path& p2, system::error_code ec);

        filesystem_error& filesystem_error(const filesystem_error&);
       ~filesystem_error();

        filesystem_error& operator=(const filesystem_error&);

        const path& path1() const;
        const path& path2() const;

        const char * what() const;
      };
} } }  // namespaces std::tbd::filesystem

The class template filesystem_error defines the type of objects thrown as exceptions to report file system errors from functions described in this Clause.

filesystem_error members

filesystem_error(const std::string& what_arg, error_code ec);

Postcondition:

Expression Value
runtime_error::what() what_arg.c_str()
code() ec
path1().empty() true
path2().empty() true
filesystem_error(const std::string& what_arg, const path_type& p1, error_code ec);

Postcondition:

Expression Value
runtime_error::what() what_arg.c_str()
code() ec
path1() Reference to stored copy of p1
path2().empty() true
filesystem_error(const std::string& what_arg, const path_type& p1, const path_type& p2, error_code ec);

Postcondition:

Expression Value
runtime_error::what() what_arg.c_str()
code() ec
path1() Reference to stored copy of p1
path2() Reference to stored copy of p2
const path& path1() const;

Returns: Reference to copy of p1 stored by the constructor, or, if none, an empty path.

const path& path2() const;

Returns: Reference to copy of p2 stored by the constructor, or, if none, an empty path.

const char* what() const;

Returns: A string containing runtime_error::what(). The exact format is unspecified. Implementations are encouraged but not required to include path1.native_string()if not empty, path2.native_string()if not empty, and system_error::what() strings in the returned string.

Enum file_type

This enum specifies constants uses to identify file types.

Constant Name Meaning
status_error An error occurred while trying to obtain the status of the file. The file simply not being found is not considered a status error.
file_not_found The file could not be found
regular_file Regular file
directory_file Directory file
symlink_file Symbolic link file
block_file Block special file
character_file Character special file
fifo_file FIFO or pipe file
socket_file Socket file
type_unknown The file exists, but it is of a system specific type not covered by any of the above cases.

Enum perms

This enum specifies bitmask constants uses to identify file permissions. The POSIX standard specifies actual values, and those values have been adopted here because they are very familiar and ingrained for many POSIX users.

Caution: Operating systems do not always support permissions as described in the table.

There is much variation in the meaning of sticky_bit; do not use it unless you understand what it means for your operating system.

There is much variation in how operating systems treat symlinks. See symlink_perms.

Windows: All permissions except write are currently ignored. There is only a single write permission; setting write permission for owner, group, or others sets write permission for all, and removing write permission for owner, group, or others removes write permission for all.

Name Value
(octal)
POSIX
macro
Definition or notes

no_perms

0 There are no permissions set for the file. Note: file_not_found is no_perms rather than perms_not_known
owner_read0400 S_IRUSR Read permission, owner
owner_write0200 S_IWUSR Write permission, owner
owner_exe0100 S_IXUSR Execute/search permission, owner
owner_all0700 S_IRWXU Read, write, execute/search by owner; owner_read | owner_write | owner_exe
group_read040 S_IRGRP Read permission, group
group_write020 S_IWGRP Write permission, group
group_exe010 S_IXGRP Execute/search permission, group
group_all070 S_IRWXG Read, write, execute/search by group; group_read | group_write | group_exe
others_read04 S_IROTH Read permission, others
others_write02 S_IWOTH Write permission, others
others_exe01 S_IXOTH Execute/search permission, others
others_all07 S_IRWXO Read, write, execute/search by others; others_read | others_write | others_exe
all_all0777 owner_all | group_all | others_all
set_uid_on_exe04000 S_ISUID Set-user-ID on execution
set_gid_on_exe02000 S_ISGID Set-group-ID on execution
sticky_bit 01000 S_ISVTX Meaning varies; see http:en.wikipedia.org/wiki/Sticky_bit
perms_mask07777   all_all | set_uid_on_exe | set_gid_on_exe | sticky_bit
perms_not_known0xFFFF The permissions are not known, such as when a file_status object is created without specifying the permissions

add_perms

0x1000

permissions() adds the argument permission bits to the file's current bits

remove_perms0x2000 permissions() removes the argument permission bits from the file's current bits
symlink_perms0x4000 On POSIX permissions() resolves symlinks unless symlink_perms is specified. Meaningless on Windows as permissions() never resolves symlinks. Meaningless on Mac OS X and some other BSD systems as permissions() always resolves symlinks. Get over it.

Class file_status

namespace std { namespace tbd { namespace filesystem {

      class file_status
      {
      public:

        // constructors
        file_status() noexcept;
        explicit file_status(file_type ft, perms prms = perms_not_known) noexcept;

        // compiler generated
        file_status(const file_status&) noexcept;
        file_status& operator=(const file_status&) noexcept;
       ~file_status() noexcept;

        // observers
        file_type  type() const noexcept;
        perms      permissions() const noexcept;

        // modifiers
        void       type(file_type ft) noexcept;
        void       permissions(perms prms) noexcept;
      };
} } }  // namespaces std::tbd::filesystem

An object of type file_status stores information about the type and permissions of a file.

file_status constructors

explicit file_status() noexcept;

Postconditions: type() == status_error, permissions() == perms_not_known.

explicit file_status(file_type ft, perms prms = perms_not_known) noexcept;

Postconditions: type() == ft, permissions() == prms.

file_status observers

file_type type() const noexcept;

Returns: The value of type() specified by the postconditions of the most recent call to a constructor, operator=, or type(file_type) function.

perms permissions() const noexcept;

Returns: The value of permissions() specified by the postconditions of the most recent call to a constructor, operator=, or permissions(perms) function.

file_status modifiers

void type(file_type ft) noexcept;

Postconditions: type() == ft.

void permissions(perms prms) noexcept;

Postconditions: permissions() == prms.

Class directory_entry

namespace std { namespace tbd { namespace filesystem {

      class directory_entry
      {
      public:

        // constructors and destructor
        directory_entry();
        directory_entry(const directory_entry&);
        explicit directory_entry(const path_type& p, file_status st=file_status(),
          file_status symlink_st=file_status());
       ~directory_entry(); 

        // modifiers
        directory_entry& operator=(const directory_entry&);
        void assign(const path_type& p, file_status st=file_status(),
          file_status symlink_st=file_status());
        void replace_filename(const path& p, file_status st=file_status(),
          file_status symlink_st=file_status());

        // observers
        const path&  path() const;
        file_status  status() const;
        file_status  status(system::error_code& ec) const;
        file_status  symlink_status() const;
        file_status  symlink_status(system::error_code& ec) const;

        bool operator< (const directory_entry& rhs);
        bool operator==(const directory_entry& rhs); 
        bool operator!=(const directory_entry& rhs); 
        bool operator< (const directory_entry& rhs);
        bool operator<=(const directory_entry& rhs);
        bool operator> (const directory_entry& rhs);
        bool operator>=(const directory_entry& rhs);
      private:
        path_type            m_path;           // for exposition only
        mutable file_status  m_status;         // for exposition only; stat()-like
        mutable file_status  m_symlink_status; // for exposition only; lstat()-like
      };

} } }  // namespaces std::tbd::filesystem

A directory_entry object stores a path object, a file_status object for non-symbolic link status, and a file_status object for symbolic link status. The file_status objects act as value caches.

[Note: Because status()on a pathname may be a very expensive operation, some operating systems provide status information as a byproduct of directory iteration. Caching such status information can result is significant time savings. Cached and non-cached results may differ in the presence of file system races. -- end note]

Actual cold-boot timing of iteration over a directory with 15,047 entries was six seconds for non-cached status queries versus one second for cached status queries. Windows XP, 3.0 GHz processor, with a moderately fast hard-drive. Similar speedups are expected on Linux and BSD-derived systems that provide status as a by-product of directory iteration.

directory_entry constructors

directory_entry();

Postcondition:

Expression Value
path().empty() true
status() file_status()
symlink_status() file_status()
explicit directory_entry(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status());

Postcondition:

Expression Value
path() p
status() st
symlink_status() symlink_st

directory_entry modifiers

void assign(const path_type& p, file_status st=file_status(), file_status symlink_st=file_status());

Postcondition:

Expression Value
path() p
status() st
symlink_status() symlink_st
void replace_filename(const path& p, file_status st=file_status(), file_status symlink_st=file_status());

Postcondition:

Expression Value
path() path().branch() / s
status() st
symlink_status() symlink_st

directory_entry observers

const path& path() const;

Returns: m_path

file_status status() const;
file_status status(system::error_code& ec) const;

Effects: As if,

if ( !status_known( m_status ) )
{
  if ( status_known(m_symlink_status) && !is_symlink(m_symlink_status) )
    { m_status = m_symlink_status; }
  else { m_status = status(m_path[, ec]); }
}

Returns: m_status

Throws: As specified in Error reporting.

file_status  symlink_status() const;
file_status  symlink_status(system::error_code& ec) const;

Effects: As if,

if ( !status_known( m_symlink_status ) )
{
  m_symlink_status = symlink_status(m_path[, ec]);
}

Returns: m_symlink_status

Throws: As specified in Error reporting.

bool operator==(const directory_entry& rhs);

Returns: m_path == rhs.m_path.

bool operator!=(const directory_entry& rhs);

Returns: m_path != rhs.m_path.

bool operator< (const directory_entry& rhs);

Returns: m_path < rhs.m_path.

bool operator<=(const directory_entry& rhs);

Returns: m_path <= rhs.m_path.

bool operator> (const directory_entry& rhs);

Returns: m_path > rhs.m_path.

bool operator>=(const directory_entry& rhs);

Returns: m_path >= rhs.m_path.

Class directory_iterator

Objects of type directory_iterator provide standard library compliant iteration over the contents of a directory. Also see class recursive_directory_iterator.

namespace std { namespace tbd { namespace filesystem {

      class directory_iterator
      {
      public:
        // member functions

        directory_iterator() noexcept;  // creates the "end" iterator
        directory_iterator(const directory_iterator&);
        explicit directory_iterator(const path& p);
        directory_iterator(const path& p, system::error_code& ec);
       ~directory_iterator();

        directory_iterator& operator=(const directory_iterator&);

        directory_iterator& operator++();
        directory_iterator& increment(system::error_code& ec);

        // other members as required by
        //  C++ Std, 24.1.1 Input iterators [input.iterators]
      };

} } }  // namespaces std::tbd::filesystem

directory_iterator satisfies the requirements of an input iterator (C++ Std, 24.2.1, Input iterators [input.iterators]).

A directory_iterator reads successive elements from the directory for which it was constructed, as if by calling POSIX readdir_r(). After a directory_iterator is constructed, and every time operator++ is called, it reads a directory element and stores information about it in a object of type directory_entry. operator++ is not equality preserving; that is, i == j does not imply that ++i == ++j.

[Note: The practical consequence of not preserving equality is that directory iterators can only be used for single-pass algorithms. --end note]

If the end of the directory elements is reached, the iterator becomes equal to the end iterator value. The constructor directory_iterator() with no arguments always constructs an end iterator object, which is the only legitimate iterator to be used for the end condition. The result of operator* on an end iterator is not defined. For any other iterator value a const directory_entry& is returned. The result of operator-> on an end iterator is not defined. For any other iterator value a const directory_entry* is returned.

Two end iterators are always equal. An end iterator is not equal to a non-end iterator.

The above wording is based on the Standard Library's istream_iterator wording.

The result of calling the path() member of the directory_entry object obtained by dereferencing a directory_iterator is a reference to a path object composed of the directory argument from which the iterator was constructed with filename of the directory entry appended as if by operator/=.

Directory iteration shall not yield directory entries for the current (dot) and parent (dot dot) directories.

The order of directory entries obtained by dereferencing successive increments of a directory_iterator is unspecified.

[Note: Programs performing directory iteration may wish to test if the path obtained by dereferencing a directory iterator actually exists. It could be a symbolic link to a non-existent file. Programs recursively walking directory trees for purposes of removing and renaming entries may wish to avoid following symbolic links.

If a file is removed from or added to a directory after the construction of a directory_iterator for the directory, it is unspecified whether or not subsequent incrementing of the iterator will ever result in an iterator whose value is the removed or added directory entry. See POSIX readdir_r(). --end note]

directory_iterator members

directory_iterator() noexcept;

Effects: Constructs the end iterator.

explicit directory_iterator(const path& p);
directory_iterator(const path& p, system::error_code& ec);

Effects: Constructs a iterator representing the first entry in the directory p resolves to, if any; otherwise, the end iterator.

Throws: As specified in Error reporting.

[Note: To iterate over the current directory, use directory_iterator(".") rather than directory_iterator(""). -- end note]

directory_iterator& operator++();
directory_iterator& increment(system::error_code& ec);

Effects: As specified by the C++ Standard, 24.1.1 Input iterators [input.iterators]

Returns: *this.

Throws: As specified in Error reporting.

Class recursive_directory_iterator

Objects of type recursive_directory_iterator provide standard library compliant iteration over the contents of a directory, including recursion into its sub-directories.

namespace std { namespace tbd { namespace filesystem {

      class recursive_directory_iterator :
        public iterator<input_iterator_tag, directory_entry>
      {
      public:

        // constructors and destructor
        recursive_directory_iterator() noexcept;
        recursive_directory_iterator(const recursive_directory_iterator&);
        explicit recursive_directory_iterator(const path& p,
          symlink_option opt = symlink_option::none);
        recursive_directory_iterator(const path& p,
          symlink_option opt, system::error_code& ec);
        recursive_directory_iterator(const path& p, system::error_code& ec);
       ~recursive_directory_iterator();

        // observers
        int level() const noexcept;
        bool no_push_pending() const noexcept;

        // modifiers
        recursive_directory_iterator& operator=(const recursive_directory_iterator&);

        recursive_directory_iterator& operator++();
        recursive_directory_iterator& increment(system::error_code& ec);

        void pop();
        void no_push(bool value=true);

        // other members as required by
        //  C++ Std, Input iterators [input.iterators]

      private:
        // actual data members will probably be stored in a shared object,
        // or some similar mechanism, to achieve the required input iterator
        // copy semantics
        int            m_level;    // for exposition only
        bool           m_no_push;  // for exposition only
        symlink_option m_options;  // for exposition only
      };

} } }  // namespaces std::tbd::filesystem

The behavior of a recursive_directory_iterator is the same as a directory_iterator unless otherwise specified.

recursive_directory_iterator() noexcept;

Effects: Constructs the end iterator.

explicit recursive_directory_iterator(const path& p, symlink_option opt = symlink_option::none);
recursive_directory_iterator(const path& p, symlink_option opt, system::error_code& ec);
recursive_directory_iterator(const path& p, system::error_code& ec);

Effects:  Constructs a iterator representing the first entry in the directory p resolves to, if any; otherwise, the end iterator.

Postcondition: Unless the end iterator was constructed, level() == 0 && no_push_pending() == false && m_options == opt. For the signature without a symlink_option argument, opt is assumed to be symlink_option::none.

Throws: As specified in Error reporting.

[Note: To iterate over the current directory, use recursive_directory_iterator(".") rather than recursive_directory_iterator(""). -- end note]

[Note: By default, recursive_directory_iterator does not follow directory symlinks. To follow directory symlinks, specify opt as symlink_option::recurse -- end note]

int level() const noexcept;

Requires: *this != recursive_directory_iterator().

Returns: m_level.

bool no_push_pending() const noexcept;

Requires: *this != recursive_directory_iterator().

Returns: m_no_push.

recursive_directory_iterator& operator++();
recursive_directory_iterator& increment(system::error_code& ec);

Effects: As specified by the C++ Standard, 24.1.1 Input iterators [input.iterators], except:

Postcondition: no_push_pending() == false.

Returns: *this.

Throws: As specified in Error reporting.

void pop();

Requires: *this != recursive_directory_iterator().

Effects: If level() == 0, set *this to recursive_directory_iterator(). Otherwise, --m_level, cease iteration of the directory currently being iterated over, and continue iteration over the parent directory.

void no_push(bool value=true);

Requires: *this != recursive_directory_iterator().

Postcondition: no_push_pending() == value.

[Note: no_push() is used to prevent unwanted recursion into a directory. --end note]

Operational functions

Operational functions query or modify files, including directories, in external storage.

Operational functions access a file by resolving an object of class path to a particular file in a file hierarchy. The path is resolved as if by the POSIX Pathname Resolution mechanism.

[Note: Because hardware failures, network failures, file system races, and many other kinds of errors occur frequently in file system operations, users should be aware that any filesystem operational function, no matter how apparently innocuous, may encounter an error. See Error reporting. -- end note]

Operational function specifications

path absolute(const path& p, const path& base=current_path());

Returns: A absolute path composed according to the following table

  p.has_root_directory() !p.has_root_directory()
p.has_root_name() return p return p.root_name() / absolute(base).root_directory()
/ absolute(base).relative_path() / p.relative_path()
!p.has_root_name() return absolute(base).root_name()
/ p
return absolute(base) / p

[Note: For the returned path, rp, rp.is_absolute() is true. -- end note]

Throws: If base.is_absolute() is true, throws only if memory allocation fails.

path canonical(const path& p, const path& base = current_path());
path canonical(const path& p, system::error_code& ec);
path canonical(const path& p, const path& base, system::error_code& ec);

Overview: Converts p, which must exist, to an absolute path that has no symbolic link, dot, or dot-dot elements.

Returns: A canonical path that refers to the same file system object as absolute(p,base). For the overload without a base argument, base is current_path().

Throws:  As specified in Error reporting.

Remarks: !exists(p) is an error.

[Note: Canonical pathnames allow security checking of a path (eg. does this path live in /home/goodguy or /home/badguy?)  -- end note]

void copy(const path& from, const path& to);
void copy(const path& from, const path& to, system::error_code& ec);

Effects: As if

file_status s(symlink_status(from[, ec]));
if(is_symlink(s))
  copy_symlink(from, to[, ec]);
else if(is_directory(s))
  copy_directory(from, to[, ec]);
else if(is_regular_file(s))
  copy_file(from, to, copy_option::fail_if_exists[, ec]);
else
 Report error as specified in Error reporting.

Throws: As specified in Error reporting.

void copy_directory(const path& from, const path& to);
void copy_directory(const path& from, const path& to, system::error_code& ec);

Effects:

Throws: As specified in Error reporting.

void copy_file(const path& from, const path& to);
void copy_file(const path& from, const path& to, system::error_code& ec);

Effects: copy_file(from, to, copy_option::fail_if_exists[, ec]).

Throws: As specified in Error reporting.

void copy_file(const path& from, const path& to, copy_option option);
void copy_file(const path& from, const path& to, copy_option option, system::error_code& ec);

Effects: If option == copy_option::fail_if_exists && exists(to), an error is reported. Otherwise, the contents and attributes of the file from resolves to are copied to the file to resolves to.

Throws: As specified in Error reporting.

void copy_symlink(const path& existing_symlink, const path& new_symlink);
void copy_symlink(const path& existing_symlink, const path& new_symlink, system::error_code& ec);

Effects: create_symlink(read_symlink(existing_symlink[, ec]), new_symlink[, ec]).

Throws: As specified in Error reporting.

bool create_directories(const path& p);
bool create_directories(const path& p, system::error_code& ec);

Requires: p.empty() ||
forall px: px == p || is_parent(px, p): is_directory(px) || !exists( px )

Postcondition: is_directory(p)

Returns: The value of !exists(p) prior to the establishment of the postcondition.

Throws: As specified in Error reporting.

bool create_directory(const path& p);
bool create_directory(const path& p, system::error_code& ec);

Effects: Attempts to create the directory p resolves to, as if by POSIX mkdir() with a second argument of S_IRWXU|S_IRWXG|S_IRWXO.

Postcondition: is_directory(p)

Returns: true if a new directory was created, otherwise false.

Throws: As specified in Error reporting.

void create_directory_symlink(const path& to, const path& new_symlink);
void create_directory_symlink(const path& to, const path& new_symlink, system::error_code& ec);

Effects: Establishes the postcondition, as if by POSIX symlink().

Postcondition: new_symlink resolves to a symbolic link file that contains an unspecified representation of to.

Throws: As specified in Error reporting.

[Note: Some operating systems, such as Windows, require symlink creation to identify that the link is to a directory. Portable code should use create_directory_symlink() to create directory symlinks rather than create_symlink() -- end note]

[Note: Some operating systems do not support symbolic links at all or support them only for regular files. Some file systems do not support symbolic links regardless of the operating system - the FAT file system used on memory cards and flash drives, for example. -- end note]

void create_hard_link(const path& to, const path& new_hard_link);
void create_hard_link(const path& to, const path& new_hard_link, system::error_code& ec);

Effects: Establishes the postcondition, as if by POSIX link().

Postcondition:

Throws: As specified in Error reporting.

[Note: Some operating systems do not support hard links at all or support them only for regular files. Some file systems do not support hard links regardless of the operating system - the FAT file system used on memory cards and flash drives, for example. Some file systems limit the number of links per file. -- end note]

void create_symlink(const path& to, const path& new_symlink);
void create_symlink(const path& to, const path& new_symlink, system::error_code& ec);

Effects: Establishes the postcondition, as if by POSIX symlink().

Postcondition: new_symlink resolves to a symbolic link file that contains an unspecified representation of to.

Throws: As specified in Error reporting.

[Note: Some operating systems do not support symbolic links at all or support them only for regular files. Some file systems do not support symbolic links regardless of the operating system - the FAT system used on memory cards and flash drives, for example. -- end note]

path current_path();
path current_path(system::error_code& ec);

Returns: The current working directory path, as if by POSIX getcwd(). is_absolute() is true for the returned path.

Throws: As specified in Error reporting.

[Note: The current_path() name was chosen to emphasize that the return is a path, not just a single directory name.

The current path as returned by many operating systems is a dangerous global variable. It may be changed unexpectedly by a third-party or system library functions, or by another thread.  -- end note]

void current_path(const path& p);
void current_path(const path& p, system::error_code& ec);

Effects: Establishes the postcondition, as if by POSIX chdir().

Postcondition: equivalent(p, current_path()).

Throws: As specified in Error reporting.

[Note: The current path for many operating systems is a dangerous global state. It may be changed unexpectedly by a third-party or system library functions, or by another thread.  -- end note]

bool exists(file_status s) noexcept;

Returns: status_known(s) && s.type() != file_not_found

bool exists(const path& p);
bool exists(const path& p, system::error_code& ec) noexcept;

Returns: exists(status(p)) or exists(status(p, ec)), respectively.

Throws: filesystem_error; overload with error_code& throws nothing.

bool equivalent(const path& p1, const path& p2);
bool equivalent(const path& p1, const path& p2, system::error_code& ec);

Effects: Determines file_status s1 and s2, as if by status(p1) and  status(p2), respectively.

Returns: true, if sf1 == sf2 and p1 and p2 resolve to the same file system entity, else false.

Two paths are considered to resolve to the same file system entity if two candidate entities reside on the same device at the same location. This is determined as if by the values of the POSIX stat structure, obtained as if by stat() for the two paths, having equal st_dev values and equal st_ino values.

[Note: POSIX requires that "st_dev must be unique within a Local Area Network". Conservative POSIX implementations may also wish to check for equal st_size and st_mtime values. Windows implementations may use GetFileInformationByHandle() as a surrogate for stat(), and consider "same" to be equal values for dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow, nFileSizeHigh, nFileSizeLow, ftLastWriteTime.dwLowDateTime, and ftLastWriteTime.dwHighDateTime. -- end note]

Throws: filesystem_error if (!exists(s1) && !exists(s2)) || (is_other(s1) && is_other(s2)), otherwise as specified in Error reporting.

uintmax_t file_size(const path& p);
uintmax_t file_size(const path& p, system::error_code& ec);

Returns: If exists(p) && is_regular_file(p), the size in bytes of the file p resolves to, determined as if by the value of the POSIX stat structure member st_size obtained as if by POSIX stat(). Otherwise, static_cast<uintmax_t>(-1).

Throws: As specified in Error reporting.

uintmax_t hard_link_count(const path& p);
uintmax_t hard_link_count(const path& p, system::error_code& ec);

Returns: The number of hard links for p.

Throws: As specified in Error reporting.

const path& initial_path();
const path& initial_path(system::error_code& ec);

Returns: current_path() as of the first call to initial_path().

[Note: initial_path() is not thread safe, and may return an undesirable result if called subsequent to a change to the current directory. These problems can be avoided by calling initial_path() immediately on entry to main().  --end note]

Throws: For the first call, as specified in Error reporting. Subsequent calls throw nothing.

bool is_directory(file_status s) noexcept;

Returns: s.type() == directory_file

bool is_directory(const path& p);
bool is_directory(const path& p, system::error_code& ec) noexcept;

Returns: is_directory(status(p)) or is_directory(status(p, ec)), respectively.

Throws: filesystem_error; overload with error_code& throws nothing.

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

Effects: Determines file_status s, as if by status(p, ec).

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

bool is_regular_file(file_status s) noexcept;

Returns: s.type() == regular_file

bool is_regular_file(const path& p);

Returns: is_regular_file(status(p)).

Throws: filesystem_error if status(p) would throw filesystem_error.

bool is_regular_file(const path& p, system::error_code& ec) noexcept;

Effects: Sets ec as if by status(p, ec). [Note: status_error, file_not_found and type_unknown cases set ec to error values. To distinguish between cases, call the status function directly. -- end note]

Returns: is_regular_file(status(p, ec)).

bool is_other(file_status s) noexcept;

Returns: return exists(s) && !is_regular_file(s) && !is_directory(s) && !is_symlink(s)

bool is_other(const path& p);
bool is_other(const path& p, system::error_code& ec) noexcept;

Returns: is_other(status(p)) or is_other(status(p, ec)), respectively.

Throws: filesystem_error; overload with error_code& throws nothing.

bool is_symlink(file_status s) noexcept;

Returns: s.type() == symlink_file

bool is_symlink(const path& p);
bool is_symlink(const path& p, system::error_code& ec) noexcept;

Returns: is_symlink(symlink_status(p)) or is_symlink(symlink_status(p, ec)), respectively.

Throws: filesystem_error; overload with error_code& throws nothing.

std::time_t last_write_time(const path& p);
std::time_t last_write_time(const path& p, system::error_code& ec);

Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime  obtained as if by POSIX stat().

Throws: As specified in Error reporting.

void last_write_time(const path& p, const std::time_t new_time);
void last_write_time(const path& p, const std::time_t new_time, system::error_code& ec);

Effects: Sets the time of last data modification of the file resolved to by p to new_time, as if by POSIX stat() followed by POSIX utime().

Throws: As specified in Error reporting.

[Note: A postcondition of last_write_time(p) == new_time is not specified since it might not hold for file systems with coarse time granularity. -- end note]

void permissions(const path& p, perms prms);
void permissions(const path& p, perms prms, system::error_code& ec);

Requires: !((prms & add_perms) && (prms & remove_perms)).

Effects: Applies the effective permissions bits from prms to the file p resolves to, as if by POSIX fchmodat(). The effective permission bits are determined as specified by the following table.

bits present in prms Effective bits applied
Neither add_perms nor remove_perms prms & perms_mask
add_perms

status(p).permissions() | (prms & perms_mask)

remove_perms status(p).permissions() & ~(prms & perms_mask)

[Note: Conceptually permissions are viewed as bits, but the actual implementation may use some other mechanism. -- end note]

Throws: As specified in Error reporting.

path read_symlink(const path& p);
path read_symlink(const path& p, system::error_code& ec);

Returns:  If p resolves to a symbolic link, a path object containing the contents of that symbolic link. Otherwise an empty path object.

Throws: As specified in Error reporting. [Note: It is an error if p does not resolve to a symbolic link. -- end note]

bool remove(const path& p);
bool remove(const path& p, system::error_code& ec);

Effects:  If exists(symlink_status(p,ec)), it is removed as if by POSIX remove().

[Note: A symbolic link is itself removed, rather than the file it resolves to being removed. -- end note]

Postcondition: !exists(symlink_status(p)).

Returns:  false if p did not exist in the first place, otherwise true.

Throws: As specified in Error reporting.

uintmax_t remove_all(const path& p);
uintmax_t remove_all(const path& p, system::error_code& ec);

Effects:  Recursively deletes the contents of p if it exists, then deletes file p itself, as if by POSIX remove().

[Note: A symbolic link is itself removed, rather than the file it resolves to being removed. -- end note]

Postcondition: !exists(p)

Returns: The number of files removed.

Throws: As specified in Error reporting.

void rename(const path& old_p, const path& new_p);
void rename(const path& old_p, const path& new_p, system::error_code& ec);

Effects: Renames old_p to new_p, as if by POSIX rename().

[Note: If old_p and new_p resolve to the same existing file, no action is taken. Otherwise, if new_p resolves to an existing non-directory file, it is removed, while if new_p resolves to an existing directory, it is removed if empty on POSIX but is an error on Windows. A symbolic link is itself renamed, rather than the file it resolves to being renamed. -- end note]

Throws: As specified in Error reporting.

void resize_file(const path& p, uintmax_t new_size);
void resize_file(const path& p, uintmax_t new_size, system::error_code& ec);

Postcondition: file_size() == new_size.

Throws: As specified in Error reporting.

Remarks: Achieves its postconditions as if by POSIX truncate().

space_info space(const path& p);
space_info space(const path& p, system::error_code& ec);

Returns: An object of type space_info. The value of the space_info object is determined as if by using POSIX statvfs() to obtain a POSIX struct statvfs, and then multiplying its f_blocks, f_bfree, and f_bavail members by its f_frsize member, and assigning the results to the capacity, free, and available members respectively. Any members for which the value cannot be determined shall be set to -1.

Throws: As specified in Error reporting.

file_status status(const path& p);

Effects: As if:

system::error_code ec;
file_status result = status(p, ec);
if (result == status_error)
  throw filesystem_error(implementation-supplied-message, p, ec);
return result;

Returns: See above.

Throws: filesystem_error. [Note: result values of file_status(file_not_found)and file_status(type_unknown) are not considered failures and do not cause an exception to be thrown. -- end note]

file_status status(const path& p, system::error_code& ec) noexcept;

Effects:

If possible, determines the attributes of the file p resolves to, as if by POSIX stat().

If, during attribute determination, the underlying file system API reports an error, sets ec to indicate the specific error reported. Otherwise, ec.clear().

[Note: This allows users to inspect the specifics of underlying API errors even when the value returned by status() is not file_status(status_error)--end note]

Returns:

If ec != error_code():

[Note: These semantics distinguish between p being known not to exist, p existing but not being able to determine its attributes, and there being an error that prevents even knowing if p exists. These distinctions are important to some use cases. --end note]

Otherwise,

Remarks: If a symbolic link is encountered during pathname resolution, pathname resolution continues using the contents of the symbolic link.

bool status_known(file_status s) noexcept;

Returns: s.type() != status_error

file_status symlink_status(const path& p);
file_status symlink_status(const path& p, system::error_code& ec) noexcept;

Effects:  Same as status(), above, except that the attributes of p are determined as if by POSIX lstat().

Returns: Same as status(), above, except that if the attributes indicate a symbolic link, as if by POSIX S_ISLNK(), return file_status(symlink_file).

Remarks: Pathname resolution terminates if p names a symbolic link.

Throws: filesystem_error; overload with error_code& throws nothing.

path system_complete(const path& p);
path system_complete(const path& p, system::error_code& ec);

Effects: Composes an absolute path from p, using the same rules used by the operating system to resolve a path passed as the filename argument to standard library open functions.

Returns: The composed path.

Postcondition: For the returned path, rp, rp.is_absolute() is true.

Throws: As specified in Error reporting.

[Note: For POSIX, system_complete(p) has the same semantics as complete(p, current_path()).

For Windows, system_complete(p) has the same semantics as complete(ph, current_path()) if p.is_absolute() || !p.has_root_name() or p and base have the same root_name(). Otherwise it acts like complete(p, kinky), where kinky is the current directory for the p.root_name() drive. This will be the current directory of 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 often useful, they are also very error-prone.

See complete() note for usage suggestions. -- end note]

path temp_directory_path();
path temp_directory_path(system::error_code& ec);

Returns: A directory path suitable for temporary files under the conventions of the operating system. The specifics of how this path is determined are implementation defined. An error shall be reported if !exists(p) || !is_directory(p), where p is the path to be returned.

POSIX: The path supplied by the first environment variable found in the list TMPDIR, TMP, TEMP, TEMPDIR. If none of these are found, "/tmp".

Windows: The path reported by the Windows GetTempPath API function.

Throws: As specified in Error reporting.

[Note: The temp_directory_path() name was chosen to emphasize that the return is a path, not just a single directory name.  -- end note]

path unique_path(const path& model="%%%%-%%%%-%%%%-%%%%");
path unique_path(const path& model, system::error_code& ec);

The unique_path function generates a path name suitable for creating temporary files, including directories. The name is based on a model that uses the percent sign character to specify replacement by a random hexadecimal digit. [Note: The more bits of randomness in the generated path name, the less likelihood of prior existence or being guessed. Each replacement hexadecimal digit in the model adds four bits of randomness. The default model thus provides 64 bits of randomness. This is sufficient for most applications. --end note]

Returns: A path identical to model, except that each occurrence of a percent sign character is replaced by a random hexadecimal digit character in the range 0-9, a-f.

Throws: As specified in Error reporting.

Remarks: Implementations are encouraged to obtain the required randomness via a cryptographically secure pseudo-random number generator, such as one provided by the operating system. [Note: Such generators may block until sufficient entropy develops. --end note]

End of new Clause.

Modify File streams [fstreams] as follows:

To class basic_filebuf public members add:

basic_filebuf<charT,traits>* open(const path& p, std::ios_base::openmode mode);

To class basic_ifstream public members add:

explicit basic_ifstream(const path& p, std::ios_base::openmode mode=std::ios_base::in)
void open(const path& p, std::ios_base::openmode mode=std::ios_base::in);

To class basic_ofstream public members add:

explicit basic_ofstream(const path& p, std::ios_base::openmode mode=std::ios_base::out);
void open(const path& p, std::ios_base::openmode mode=std::ios_base::out);

To class basic_fstream public members add:

explicit basic_fstream(const path& p,
  std::ios_base::openmode mode=std::ios_base::in | std::ios_base::out);
void open(const path& p,
  std::ios_base::openmode mode=std::ios_base::in | std::ios_base::out);

End of proposed wording.


Issues List


Issue 1: What is the appropriate namespace?    Status: Tentatively resolved

Discussion

The N3335 proposal places the library in namespace std::tr2::files. Rationale for a sub-namespace is that the library uses several names that don't seem appropriate for namespace tr2 since full standardization would then put the names into std. The function names remove and rename are of particular concern because these functions differ in behavior from current standard library functions with those names. It also doesn't seem desirable to preempt names like equivalent and status.

Resolution

Kona: Strong support for filesystem as the library's namespace. Strong support for a technical report namespace that alerts uses that contents are likely to change if and when they later get moved into the standard.

No decision yet on a TR namespace; experimental being used as a placeholder. Thus the full namespace is changed to std::experimental::filesystem.


Issue 2: Excessive use of const codecvt_type& arguments    Status: Open

Discussion

Users sometimes need to do path conversions that use something other than the imbued codecvt facet. The need is particularly acute in multi-threaded applications where changing the imbued facet would introduce a data race. That said, providing an optional const codecvt_type& argument for every function where the need might possibly arise is excessive because its use is so rare and it adds considerable interface clutter.

Proposed resolution

Kona:

Remove all existing class path const codecvt_type& arguments.

Beman to pursue separate encoding conversion functionality, per Thursday N3336 "Adapting standard library strings and IO to a Unicode World" discussion. See Kona wiki.

If a separate encoding conversion facility isn't possible, then some form of minimal class path encoding conversion facility will be needed. But..., the LWG would like to see use cases and clearer explanation of motivation before deciding on specifics, and be very sure that there is no way to achieve with existing std library functionality, albeit with some loss of efficiency.


Issue 3: Possible "implicit cast to native type"?     Status: Open

Discussion

In Bloomington there was discussion of "implicit cast to implicit cast to native OS type to inter operate with existing iostream library and native functions instead of modifying fstream".

Proposed resolution

Kona: The Dinkumware/Microsoft implementation has added an implicit conversion to the string type, eliminating any need to modify fstream. (Discussion: might be safer to make the implicit conversion protected, then make fstream classes friends).

Action: Beman to investigate, test, as avoiding modification of existing header and classes is much desired.


Issue 4: Given move semantics, it is best not to return const strings.     Status: Resolved

Discussion

The issue title pretty much says it all.

Proposed resolution

Kona: Return plain strings. Remove the permission for implementations to return const refs, since uses are not in performace critical code and subtle portability bugs may occur.

Action: Beman to apply to proposed wording.


Issue 5: Is there a way to handle characters that are illegal for particular OS?     Status: NAD

Discussion

Question raised by Pablo in Bloomington.

Proposed resolution

Beman suggests NAD, Future. I've done some work on this, including looking at systems like OpenVMS that have an escape mechanism to handle otherwise unrepresentable characters. There was a comment to that effect in N3239. I believe it should be deferred to some future release since (1) it is complex enough that I'd like to see actual implementation and use experience (presumably via Boost), and (2) I can't recall a user ever requesting such a feature.

Kona: No consensus for change, since there doesn't appear to be any compelling use case.


Issue 6: Could allocator support be added to class path?     Status: Open

Discussion

Question raised by a committee member in private email.

Kona: Much discussion.

Action: Alisdair to write paper, based on a real implementation, so that it is possible to assess the impact on interface, performance, etc.

Post-Kona: Alisdair will defer paper until after TR.


Issue 7: How should class path inserter and extractor be specified?       Status: Resolved

Discussion

Class path currently is specified to used the Boost detail quoted stream manipulator. A path object is inserted delimited by quotes, and extracted accordingly, ensuring that paths containing spaces are round-tripped correctly.  Quotes in the path itself are escaped, and io state is saved and restored.

See http://www.boost.org/doc/libs/1_48_0/libs/io/doc/quoted_manip.html

Since the standard can't specify behavior in terms of something in Boost, we have to change the specification. Since the quoted stream manipulator is a handy little component, the issue is raised as to whether it should go in TR2.

Resolution

Kona: Specify the path inserter and extractor to have the desired behavior without reference to how it is achieved. (If someone wants to propose a quoted manipulator, that's a separate proposal for a different TR.)

Action:  Beman to apply to proposed wording.


Path decomposition table

The table is generated by a program compiled with the Boost implementation.

Shaded entries indicate cases where POSIX and Windows implementations yield different results. The top value is the POSIX result and the bottom value is the Windows result.

Constructor
argument
Iteration
over
Elements
string() generic_
string()
root_
path()
root_
name()
root_
directory()
relative_
path()
parent_
path()
filename()
empty empty empty empty empty empty empty empty empty empty
. . . . empty empty empty . empty .
.. .. .. .. empty empty empty .. empty ..
foo foo foo foo empty empty empty foo empty foo
/ / / / / empty / empty empty /
/foo /,foo /foo /foo / empty / foo / foo
foo/ foo,. foo/ foo/ empty empty empty foo/ foo .
/foo/ /,foo,. /foo/ /foo/ / empty / foo/ /foo .
foo/bar foo,bar foo/bar foo/bar empty empty empty foo/bar foo bar
/foo/bar /,foo,bar /foo/bar /foo/bar / empty / foo/bar /foo bar
//net //net //net //net //net //net empty empty empty //net
//net/foo //net,/,foo //net/foo //net/foo //net/ //net / foo //net/ foo
///foo/// /,foo,. ///foo/// ///foo/// / empty / foo/// ///foo .
///foo///bar /,foo,bar ///foo///bar ///foo///bar / empty / foo///bar ///foo bar
/. /,. /. /. / empty / . / .
./ .,. ./ ./ empty empty empty ./ . .
/.. /,.. /.. /.. / empty / .. / ..
../ ..,. ../ ../ empty empty empty ../ .. .
foo/. foo,. foo/. foo/. empty empty empty foo/. foo .
foo/.. foo,.. foo/.. foo/.. empty empty empty foo/.. foo ..
foo/./ foo,.,. foo/./ foo/./ empty empty empty foo/./ foo/. .
foo/./bar foo,.,bar foo/./bar foo/./bar empty empty empty foo/./bar foo/. bar
foo/.. foo,.. foo/.. foo/.. empty empty empty foo/.. foo ..
foo/../ foo,..,. foo/../ foo/../ empty empty empty foo/../ foo/.. .
foo/../bar foo,..,bar foo/../bar foo/../bar empty empty empty foo/../bar foo/.. bar
c: c: c: c: empty
c:
empty
c:
empty c:
empty
empty c:
c:/ c:,.
c:,/
c:/ c:/ empty
c:/
empty
c:
empty
/
c:/
empty
c: .
/
c:foo c:foo
c:,foo
c:foo c:foo empty
c:
empty
c:
empty c:foo
foo
empty
c:
c:foo
foo
c:/foo c:,foo
c:,/,foo
c:/foo c:/foo empty
c:/
empty
c:
empty
/
c:/foo
foo
c:
c:/
foo
c:foo/ c:foo,.
c:,foo,.
c:foo/ c:foo/ empty
c:
empty
c:
empty c:foo/
foo/
c:foo .
c:/foo/ c:,foo,.
c:,/,foo,.
c:/foo/ c:/foo/ empty
c:/
empty
c:
empty
/
c:/foo/
foo/
c:/foo .
c:/foo/bar c:,foo,bar
c:,/,foo,bar
c:/foo/bar c:/foo/bar empty
c:/
empty
c:
empty
/
c:/foo/bar
foo/bar
c:/foo bar
prn: prn: prn: prn: empty
prn:
empty
prn:
empty prn:
empty
empty prn:
c:\ c:\
c:,/
c:\ c:\
c:/
empty
c:\
empty
c:
empty
\
c:\
empty
empty
c:
c:\
\
c:foo c:foo
c:,foo
c:foo c:foo empty
c:
empty
c:
empty c:foo
foo
empty
c:
c:foo
foo
c:\foo c:\foo
c:,/,foo
c:\foo c:\foo
c:/foo
empty
c:\
empty
c:
empty
\
c:\foo
foo
empty
c:\
c:\foo
foo
c:foo\ c:foo\
c:,foo,.
c:foo\ c:foo\
c:foo/
empty
c:
empty
c:
empty c:foo\
foo\
empty
c:foo
c:foo\
.
c:\foo\ c:\foo\
c:,/,foo,.
c:\foo\ c:\foo\
c:/foo/
empty
c:\
empty
c:
empty
\
c:\foo\
foo\
empty
c:\foo
c:\foo\
.
c:\foo/ c:\foo,.
c:,/,foo,.
c:\foo/ c:\foo/
c:/foo/
empty
c:\
empty
c:
empty
\
c:\foo/
foo/
c:\foo .
c:/foo\bar c:,foo\bar
c:,/,foo,bar
c:/foo\bar c:/foo\bar
c:/foo/bar
empty
c:/
empty
c:
empty
/
c:/foo\bar
foo\bar
c:
c:/foo
foo\bar
bar

Warning: Long paths on Windows and the extended-length \\?\ prefix

The Microsoft Windows "Maximum Path Length Limitation" specifies:

In the Windows API (with some exceptions ...), the maximum length for a path is MAX_PATH, which is defined as 260 characters.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. ... To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".  [C++ string literals require backslashes be doubled, of course.]

Because most Boost.Filesystem operational functions just pass the contents of a class path object to the Windows API, they do work with the extended-length prefixes. But some won't work, because to the limitations imposed by Windows. Read the following cautions carefully!

Cautions for paths with extended-length prefixes

Acknowledgements

This Filesystem Library is dedicated to my wife, Sonda, who provided the support necessary to see both a trial implementation and the proposal itself through to completion. She gave me the strength to continue after a difficult year of cancer treatment in the middle of it all.

Many people contributed technical comments, ideas, and suggestions to the Boost Filesystem Library. See http://www.boost.org/libs/filesystem/doc/index.htm#Acknowledgements.

Dietmar Kuehl contributed the original Boost Filesystem Library directory_iterator design. Peter Dimov, Walter Landry, Rob Stewart, and Thomas Witt were particularly helpful in refining the library.

The create_directories, extension, basename, and replace_extension functions were developed by Vladimir Prus. The temp_directory_path function was contributed by Jeff Flinn. David Svoboda suggested the canonical function and provided psuedo-code.

Howard Hinnant and John Maddock reviewed a draft of the version 2 proposal, and identified a number of mistakes or weaknesses, resulting in a more polished final document.

Peter Dimov suggested a single class path, with member templates to adapt to multiple string types. His idea became the basis for the version 3 path design.

References

[ISO-POSIX] ISO/IEC 9945:2003, IEEE Std 1003.1-2001, and The Open Group Base Specifications, Issue 6. Also known as The Single Unix® Specification, Version 3. Available from each of the organizations involved in its creation. For example, read online or download from www.unix.org/single_unix_specification/. The ISO JTC1/SC22/WG15 - POSIX homepage is www.open-std.org/jtc1/sc22/WG15/
[Abrahams] Dave Abrahams, Error and Exception Handling, www.boost.org/more/error_handling.html