| Filesystem Library Version 3

Boost Home Library Home Reference Tutorial FAQ Portability V3 Intro V3 Design Deprecated

# Reference Documentation

## Table of Contents

Introduction Definitions Conformance Header <filesystem> synopsis Error reporting Class path path constructors path assignments path appends path modifiers path native format observers path generic format observers path decomposition path query path iterators path deprecated functions path non-member functions path inserters and extractors Class filesystem_error filesystem_error constructors filesystem_error path1 filesystem_error path2 filesystem_error what Class directory_entry directory_entry constructors directory_entry modifiers directory_entry observers Class directory_iterator directory_iterator members Class recursive_directory_iterator Class file_status | Operational functions absolute copy_file create_directories create_directory create_hard_link create_symlink current_path exists equivalent file_size is_directory is_empty is_other is_regular_file is_symlink last_write_time read_symlink remove remove_all rename resize_file space status status_known symlink_status system_complete unique_path | File streams Path decomposition table Acknowledgements References

## Introduction

This reference documentation describes components that C++ programs may use to perform operations involving file systems, including paths, regular files, and directories.

## 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. Common types of files 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 0 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 ANSI control characters (0x00-0x31) in filenames.

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

Path: A sequence of elements that identify a location 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 uniquely identifies a file. 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 uniquely identifies a file only when considered relative to some other path. [Note: Paths "." and ".." are considered to be relative paths. --end note]

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

Generic pathname format:

> pathname:
> root-nameopt root-directoryopt relative-pathopt

> root-name:
> implementation-defined

> > > [Note: Most POSIX and Windows based operating system 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]

Race condition: 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.

## 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]

Specific operating systems such as OpenMVS, UNIX, and Windows are mentioned only for purposes of illustration or to give guidance to implementers. No slight to other operating systems is implied or intended.

The Effects and Postconditions of functions described in this reference may not be achieved in the presence of race conditions. No diagnostic is required.

If the possibility of race conditions 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]

## Header `<boost/filesystem>` synopsis

      namespace boost
      {
        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);

          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
                         };

          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
          };

          BOOST_SCOPED_ENUM_START(copy_option)
          {
            fail_if_exists,
            overwrite_if_exists
          };
          BOOST_SCOPED_ENUM_END

          // operational functions

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

          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, BOOST_SCOPED_ENUM(copy_option) option);
          void         copy_file(const path& from, const path& to, BOOST_SCOPED_ENUM(copy_option) option,
                                 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_hard_link(const path& to, const path& from);
          void         create_hard_link(const path& to, const path& from, system::error_code& ec);

          void         create_symlink(const path& to, const path& from);
          void         create_symlink(const path& to, const path& from, 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);
          bool         exists(const path& p);
          bool         exists(const path& p, system::error_code& ec);

          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);

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

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

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

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

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

          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);

          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);

          bool         status_known(file_status s);

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

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

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

        } // namespace filesystem
      } // namespace boost

## 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:

> - Uses where file system errors are truly exceptional and indicate a serious failure. Throwing an exception is the most appropriate response. This is the preferred default for most everyday programming.
> - Uses where file system system errors are routine and do not necessarily represent failure. Returning an error code is the most appropriate response. This allows application specific error handling, including simply ignoring the error.

> --end note]

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

- When a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, an exception of type `filesystem_error` is thrown.
- Failure to allocate storage is reported by throwing an exception as described in the C++ standard, 17.6.4.10 [res.on.exception.handling].
- Destructors throw nothing.

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

- If a call by the implementation to an operating system or other underlying API results in an error that prevents the function from meeting its specifications, the `system::error_code&` argument is set as appropriate appropriate for the specific error. Otherwise, `clear()` is called on the `system::error_code&` argument.
- Failure to allocate storage is reported by throwing an exception as described in the C++ standard, 17.6.4.10 [res.on.exception.handling].

## 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 may not actually exist in external storage, and may contain pathnames which are not even valid for the current operating system.

      namespace boost
      {
        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);

            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);

            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;  // native format, encoding
            const value_type*   c_str() const;   // 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
          };

        } // namespace filesystem
      } // namespace boost

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

> [Note: For POSIX-like implementations, including Unixes, Linux, and Mac OS X, `path::value_type` is `char` .

> For Windows-like implementations, including Cygwin and MinGW, `path::value_type` is `wchar_t`. --end note]

For member functions described as returning `const string`, `const wstring`, `const u16string`, or `const u32string`, implementations 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]

`InputIterator` is 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`.

`Source` is required to be one of:

- A container with a value type of `char`, `wchar_t`, `char16_t`, or `char32_t`.
- An iterator for a null terminated byte-string. The value type is required to be `char`, `wchar_t`, `char16_t`, or `char32_t`.
- A C-array. The value type is required to be `char`, `wchar_t`, `char16_t`, or `char32_t`.
- A `boost::filesystem::directory_entry`.

The specifications for certain `path` functions require that arguments in the generic pathname format be converted to native pathname format as they are stored in `pathname`. If the native format requires regular file paths and directory paths to be formatted differently, the implementation shall determine which format to use according to whether or not the last element of the generic format string is a separator. [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] [Note: POSIX and Windows use the same native format for regular file and directory pathnames, so this paragraph does not apply to them. --end note]

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.]

### `path` constructors

    path();

> Postconditions: `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, 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`.

### `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:
> > - an added separator would be redundant, or
> > - would change an relative path to an absolute path, or
> > - `p.empty()`, or
> > - `*p.native().cbegin()` is a directory separator.

> > 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:

> > - an added separator would be redundant, or
> > - would change an relative path to an absoute path, or
> > - `p.empty()`, or
> > - `*p.native().cbegin()` is a separator.

> > 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);

> Effects: Swaps the contents of the two paths.

> Throws: nothing.

> 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;

> Returns: `pathname`.

> Throws: nothing.

    const value_type* c_str() const;

> Returns: `pathname.c_str()`.

> Throws: nothing.

    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" (without the quotes)

> --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" (without the quotes)

> >     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" (without the quotes)

> --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 root-name element, if present.
- The root-directory element, if present.
- Each successive filename element, if present.
- Dot, if one or more trailing non-root slash characters are present.

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` deprecated functions

Several member functions from previous versions of `class path` have been deprecated, either because they have been renamed or because the functionality is no longer desirable or has become obsolete.

Deprecated functions available by default; will be suppressed if `BOOST_FILESYSTEM_NO_DEPRECATED` is defined:

>     path&  remove_leaf()           { return remove_filename(); }
>     path   leaf() const            { return filename(); }
>     path   branch_path() const     { return parent_path(); }
>     bool   has_leaf() const        { return !m_path.empty(); }
>     bool   has_branch_path() const { return !parent_path().empty(); }

Deprecated functions not available by default; will be supplied if `BOOST_FILESYSTEM_DEPRECATED` is defined:

>     const std::string  file_string() const               { return native_string(); }
>     const std::string  directory_string() const          { return native_string(); }
>     const std::string  native_file_string() const        { return native_string(); }
>     const std::string  native_directory_string() const   { return native_string(); }
>     const string_type  external_file_string() const      { return native(); }
>     const string_type  external_directory_string() const { return native(); }

### `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]

    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 boost
      {
        namespace filesystem
        {
          class basic_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;
          };
        } // namespace filesystem
      } // namespace boost

The class template `basic_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);

> Postconditions:

> 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);

> Postconditions:

> 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);

> Postconditions:

> Expression | Value
> `runtime_error::what()` | `w` `hat_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.

### Class `directory_entry`

      namespace boost
      {
        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(system::error_code& ec) 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
          };

        } // namespace filesystem
      } // namespace boost

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 race conditions. -- 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();

> Postconditions:

> 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());

> Postconditions:

> 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());

> Postconditions:

> 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());

> Postconditions:

> 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(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); }
> >     }
> >     else if ( &ec != &boost::throws() ) ec.clear();

> Returns: `m_status`

    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);
> >     }
> >     else if ( &ec != &boost::throws() ) ec.clear();

> Returns: `m_symlink_status`

    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 boost
      {
        namespace filesystem
        {
          class directory_iterator
            : public boost::iterator_facade< directory_iterator,
                                             directory_entry,
                                             boost::single_pass_traversal_tag >
          {
          public:
            // member functions

            directory_iterator();  // 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]
          };

        } // namespace filesystem
      } // namespace boost

`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();`

> Effects: Constructs the end iterator.

> Throws: Nothing.

    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 `directory_iterator` provide standard library compliant iteration over the contents of a directory, including recursion into its sub-directories.

      namespace boost
      {
        namespace filesystem
        {
          class recursive_directory_iterator :
            public iterator<input_iterator_tag, directory_entry >
          {
          public:

            // constructors and destructor
            recursive_directory_iterator();
            recursive_directory_iterator(const recursive_directory_iterator&);
            explicit recursive_directory_iterator(const path& p);
            recursive_directory_iterator(const path& p, system::error_code& ec);
           ~recursive_directory_iterator();

            // observers
            int level() const;
            bool no_push_request() const;

            // 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();

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

          private:
            int  m_level;           // for exposition only
            bool m_no_push_request;  // for exposition only
          };

        } // namespace filesystem
      } // namespace boost

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

- When an iterator reaches the end of the directory currently being iterated over, or when `pop()` is called, `m_level` is decremented, and iteration continues with the parent directory, until the directory specified in the constructor argument is reached.

> [Note: One of the uses of `no_push()` is to prevent unwanted recursion into a directory symlink. This may be necessary to prevent loops on some operating systems. --end note]

    recursive_directory_iterator();

> Effects: Constructs the end iterator.

> Throws: Nothing.

    explicit recursive_directory_iterator(const path& p);
    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.

> Postconditions: Unless the end iterator was constructed, `level() == 0`, `no_push_request() == false`.

> Throws: As specified in Error reporting.

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

    int level() const;

> Requires: `*this != recursive_directory_iterator()`.

> Returns: `m_level`.

> Throws: Nothing.

    bool no_push_request() const;

> Requires: `*this != recursive_directory_iterator()`.

> Returns: `m_no_push_request`.

> Throws: Nothing.

    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 that if `(*this)->is_directory() && !no_push_requested()` then `m_level` is incremented and `(*this)->path()` is recursively iterated into.

> Postconditions: `no_push_request() == 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.

> Throws: Nothing.

    void no_push();

> Requires: `*this != recursive_directory_iterator()`.

> Postconditions: `no_push_request() == true`.

> Throws: Nothing.

> [Note: One of the uses of `no_push()` is to prevent unwanted recursion into a directory symlink. This may be necessary to prevent loops on some operating systems. --end note]

### Class file_status

      namespace boost
      {
        namespace filesystem
        {
          class file_status
          {
          public:
            file_status();
            file_status(const file_status&);
            explicit file_status(file_type v=status_error);
           ~file_status();

            file_type type() const;
            void type(file_type v);
          };
        } // namespace filesystem
      } // namespace boost

An object of type `file_status` stores information about the status of a file. The internal form of the stored information is unspecified.

> [Note: The class may be extended in the future to store additional status information. --end note]

#### Members

    explicit file_status(file_type v=status_error);

> Effects: Stores `v`.

> Throws: Nothing.

    file_type type() const;

> Returns: The stored `file_type`.

    void type(file_type v);

> Effects: Stores `v`, replacing the previously stored value.

### 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, race conditions, 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 path composed according to 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`

> Postconditions: For the returned path, `rp,` `rp.is_absolute()` is true.

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

    void copy_file(const path& from, const path& to);

> Effects: `copy_file(from, to, copy_option::fail_if_exists)`.

> Throws: As specified in Error reporting.

    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, BOOST_SCOPED_ENUM(copy_option) option);
    void copy_file(const path& from, const path& to, BOOST_SCOPED_ENUM(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.

    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 )`

> Postconditions: `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_hard_link(const path& to, const path& from);
    void create_hard_link(const path& to, const path& from, system::error_code& ec);

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

> Postconditions:

> - `exists(to) && exists(from) && equivalent(to, from)`
> - The contents of the file or directory `to` resolves to are unchanged.

> 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 system used on floppy discs, memory cards and flash drives, for example. Some file systems limit the number of links per file. Thus hard links should only be used if these situations are not concerns, or if workarounds are provided. -- end note]

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

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

> Postconditions: `from` 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. Windows prior to Vista, for example, did not support symbolic links. Some file systems do not support symbolic links regardless of the operating system - the FAT system used on floppy discs, memory cards and flash drives, for example. Thus symbolic links should only be used if these situations are not concerns, or if workarounds are provided. -- 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()`.

> Postconditions: `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);

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

> Throws: Nothing.

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

> 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);

> Remarks:

> 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.

    bool is_directory(file_status s);

> Returns: `s.type() == directory_file`

> Throws: Nothing.

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

> 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);

> Returns: `s.type() == regular_file`

> Throws: Nothing.

    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);

> 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))`.

> Throws: Nothing.

    bool is_other(file_status s);

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

> Throws: Nothing.

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

> 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);

> Returns: `s.type() == symlink_file`

> Throws: Nothing.

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

> 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()`.

    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]

    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);

> Postconditions: `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);

> 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()`:

> > - If the specific error indicates that `p` cannot be resolved because some element of the path does not exist, return `file_status(file_not_found)`. [Note: POSIX errors that indicate this are ENOENT or ENOTDIR. Windows equivalents include ERROR_FILE_NOT_FOUND, ERROR_PATH_NOT_FOUND, ERROR_INVALID_NAME, ERROR_INVALID_PARAMETER, ERROR_BAD_PATHNAME, and ERROR_BAD_NETPATH. -- end note]
> > - Otherwise, if the specific error indicates that `p` can be resolved but the attributes cannot be determined, return `file_status(type_unknown)`. [Note: For example, Windows ERROR_SHARING_VIOLATION errors. For POSIX, the case never arises. -- end note]
> > - Otherwise, return `file_status(status_error)`.

> > > [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,

> > - If the attributes indicate a regular file, as if by POSIX S_ISREG(), return `file_status(regular_file)`. [Note: `regular_file` implies appropriate `<fstream>` operations would succeed, assuming no hardware, permission, access, or race condition errors. Lack of `regular_file` does not necessarily imply `<fstream>` operations would fail on a directory. -- end note]
> > - Otherwise, if the attributes indicate a directory, as if by POSIX S_ISDIR(), return `file_status(directory_file)`. [Note: `directory_file` implies `directory_iterator(p)`would succeed. -- end note]
> > - Otherwise, if the attributes indicate a block special file, as if by POSIX S_ISBLK(), return `file_status(block_file)`.
> > - Otherwise, if the attributes indicate a character special file, as if by POSIX S_ISCHR(), return `file_status(character_file)`.
> > - Otherwise, if the attributes indicate a fifo or pipe file, as if by POSIX S_ISFIFO(), return `file_status(fifo_file)`.
> > - Otherwise, if the attributes indicate a socket, as if by POSIX S_ISSOCK(), return `file_status(socket_file)`.
> > - Otherwise, return `file_status(type_unknown)`.

> Throws: Nothing.

> 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);

> Returns: `s.type() != status_error`

> Throws: Nothing.

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

> 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)`.

> Throws: Nothing.

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

    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.

> Postconditions: For the returned path, `rp,` `rp.is_absolute()` is true.

> [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 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]

### File streams - <boost/filesystem/fstream.hpp>

Replacements are provided for the file stream classes from the C++ standard library's `<fstream>` header. These replacement classes publicly inherit from the standard library classes. In the Boost.Filesystem version, constructors and open functions take `const path&` arguments instead of `const char*` arguments. There are no other differences in syntax or semantics.

    namespace boost
    {
      namespace filesystem
      {
        template < class charT, class traits = std::char_traits<charT> >
        class basic_filebuf : public std::basic_filebuf<charT,traits>
        {
        public:
          basic_filebuf<charT,traits>*
            open(const path& p, std::ios_base::openmode mode);
        };

        template < class charT, class traits = std::char_traits<charT> >
        class basic_ifstream : public std::basic_ifstream<charT,traits>
        {
        public:
          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);
        };

        template < class charT, class traits = std::char_traits<charT> >
        class basic_ofstream : public std::basic_ofstream<charT,traits>
        {
        public:
          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);
        };

        template < class charT, class traits = std::char_traits<charT> >
        class basic_fstream : public std::basic_fstream<charT,traits>
        {
        public:
          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);
        };

        typedef basic_filebuf<char> filebuf;
        typedef basic_ifstream<char> ifstream;
        typedef basic_ofstream<char> ofstream;
        typedef basic_fstream<char> fstream;

        typedef basic_filebuf<wchar_t> wfilebuf;
        typedef basic_ifstream<wchar_t> wifstream;
        typedef basic_fstream<wchar_t> wfstream;
        typedef basic_ofstream<wchar_t> wofstream;

      } // namespace filesystem
    } // namespace boost

## 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`

## 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.

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

© Copyright Beman Dawes, 2002, 2006, 2007, 2009, 2010

Distributed under the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt

Revised 02 July 2010