Boost
boost
arrow_drop_down
Boost news learn community libraries releases
Filesystem Library
Version 4

Contents
Introduction
Documentation
Using the library
Coding guidelines
Cautions
Headers
Example programs
Implementation
Macros
Building the object-library
Notes for Cygwin users
Version history
  with acknowledgements

Introduction

The Boost.Filesystem library provides facilities to manipulate files and directories, and the paths that identify them.

The features of the library include:

Many users say the interface is their primary motivation for using Boost.Filesystem. They like its use of familiar idioms based on standard library containers, iterators, and algorithms. They like having errors reported by throwing exceptions.

Documentation

Tutorial - A gentle introduction to the library, with example programs provided for you to experiment with.

Reference - Formal documentation in the style of the C++ standard for every component of the library.

FAQ - Frequently asked questions.

Portability Guide - Help for those concerned with writing code to run on multiple operating systems.

Deprecated Features - Identifies deprecated features and their replacements.

Version 4 Description - Summary of changes from Version 3.

Version 3 Introduction - Aimed at users of prior Boost.Filesystem versions.

Version 3 Design - Historical document from the start of the Version 3 design process.

Original Design - Historical document from the start of the Version 1 design process.

Do List - Boost.Filesystem development work in the pipeline.

Using the library

Boost.Filesystem is implemented as a separately compiled library, so you must install binaries in a location that can be found by your linker. If you followed the Boost Getting Started instructions, that's already been done for you.

Coding guidelines

For new code, defining BOOST_FILESYSTEM_NO_DEPRECATED before including filesystem headers is strongly recommended. This prevents inadvertent use of old features, particularly legacy function names, that have been replaced and are going to go away in the future.

Cautions

After reading the tutorial you can dive right into simple, script-like programs using the Filesystem Library! Before doing any serious work, however, there a few cautions to be aware of:

Effects and Postconditions not guaranteed in the presence of race-conditions

Filesystem function specifications follow the C++ Standard Library form, specifying behavior in terms of effects and postconditions. If a race-condition exists, a function's postconditions may no longer be true by the time the function returns to the caller.

Explanation: The state of files and directories is often globally shared, and thus may be changed unexpectedly by other threads, processes, or even other computers having network access to the filesystem. As an example of the difficulties this can cause, note that the following asserts may fail:

assert( exists( "foo" ) == exists( "foo" ) );  // (1)

remove_all( "foo" );
assert( !exists( "foo" ) );  // (2)

assert( is_directory( "foo" ) == is_directory( "foo" ) ); // (3)

(1) will fail if a non-existent "foo" comes into existence, or an existent "foo" is removed, between the first and second call to exists(). This could happen if, during the execution of the example code, another thread, process, or computer is also performing operations in the same directory.

(2) will fail if between the call to remove_all() and the call to exists() a new file or directory named "foo" is created by another thread, process, or computer.

(3) will fail if another thread, process, or computer removes an existing file "foo" and then creates a directory named "foo", between the example code's two calls to is_directory().

Exceptions

Unless otherwise specified, Boost.Filesystem functions throw basic_filesystem_error exceptions to report failures such as I/O errors. Implementations may also use C++ Standard Library functions which can throw std::bad_alloc exceptions to report memory allocation errors. These exceptions may be thrown even though the error condition leading to the exception is not explicitly specified in the function's "Throws" paragraph.

Nominally non-throwing versions are provided for operational functions that access the external file system, since these are often used in contexts where error codes may be the preferred way to report an error. Even the nominally non-throwing versions of functions will throw std::bad_alloc exceptions to report memory allocation errors. However, functions marked noexcept never throw exceptions.

Headers

The Boost.Filesystem library provides several headers:

Example programs

See the tutorial for example programs.

Implementation

The current implementation supports operating systems which provide the POSIX or Windows API's.

The library is in regular use on Apple OS X, HP-UX, IBM AIX, Linux, Microsoft Windows, SGI IRIX, and Sun Solaris operating systems using a variety of compilers. It is also used by several smart phone operating systems.

Macros

Users may define the following macros if desired. Sensible defaults are provided, so users can ignore these macros unless they have special needs.

Macro Name Default Effect if defined
BOOST_FILESYSTEM_VERSION 3 Selects the Boost.Filesystem library version. Can have values of 3 or 4. Defining to 4 also implies BOOST_FILESYSTEM_NO_DEPRECATED.
BOOST_FILESYSTEM_NO_DEPRECATED Not defined. Deprecated features are excluded from headers.
BOOST_FILESYSTEM_DYN_LINK Defined if BOOST_ALL_DYN_LINK is defined, otherwise not defined. The Boost.Filesystem library is dynamically linked. If not defined, static linking is assumed.
BOOST_FILESYSTEM_NO_LIB Defined if BOOST_ALL_NO_LIB is defined, otherwise not defined. Boost.Filesystem library does not use the Boost auto-link facility.
BOOST_FILESYSTEM_DISABLE_SENDFILE Not defined. sendfile API presence detected at library build time. Boost.Filesystem library does not use the sendfile system call on Linux. The sendfile system call started accepting regular file descriptors as the target in Linux 2.6.33.
BOOST_FILESYSTEM_DISABLE_COPY_FILE_RANGE Not defined. copy_file_range API presence detected at library build time. Boost.Filesystem library does not use the copy_file_range system call on Linux. The copy_file_range system call was introduced in Linux kernel 4.5 and started operating across filesystems in 5.3.
BOOST_FILESYSTEM_DISABLE_STATX Not defined. statx presence detected at library build time. Boost.Filesystem library does not use the statx system call on Linux. The statx system call was introduced in Linux kernel 4.11.
BOOST_FILESYSTEM_DISABLE_GETRANDOM Not defined. getrandom API presence detected at library build time. Boost.Filesystem library does not use the getrandom system call on Linux. The getrandom system call was introduced in Linux kernel 3.17.
BOOST_FILESYSTEM_DISABLE_ARC4RANDOM Not defined. arc4random API presence detected at library build time. Boost.Filesystem library does not use the arc4random_buf system call on BSD systems. The arc4random API was introduced in OpenBSD 2.1 and FreeBSD 8.0.
BOOST_FILESYSTEM_DISABLE_BCRYPT Not defined. BCrypt API presence detected at library build time. Boost.Filesystem library does not use the BCrypt API on Windows. Has no effect on other platforms.

User-defined BOOST_POSIX_API and BOOST_WINDOWS_API macros are no longer supported.

Building the object-library

The object-library will be built automatically if you are using the Boost build system. See Getting Started. It can also be built manually using a Jamfile supplied in directory libs/filesystem/build, or the user can construct an IDE project or make file which includes the object-library source files.

The object-library source files are supplied in the src directory. These source files implement the library for POSIX or Windows compatible operating systems; no implementation is supplied for other operating systems. Note that many operating systems not normally thought of as POSIX systems, such as mainframe legacy operating systems or embedded operating systems, support POSIX compatible file systems and so will work with the Filesystem Library.

The object-library can be built for static or dynamic (shared/dll) linking. This is controlled by the BOOST_ALL_DYN_LINK or BOOST_FILESYSTEM_DYN_LINK macros. See the Separate Compilation page for a description of the techniques used.

Note for Cygwin users

Cygwin version 1.7 or later is required because only versions of GCC with wide character strings are supported.

The library's implementation code treats Cygwin as a Windows platform, and thus uses the Windows API and uses Windows path syntax as the native path syntax.

Version history

Version 4

Under development - Improve compatibility with std::filesystem introduced in C++17 (original proposal: ISO C++ File System Technical Specification). The Filesystem TS was based on Boost.Filesystem Version 3, with only a small number of changes. Most user code written for Version 3 should work unchanged with Version 4. The differences can be seen in a separate section.

Version 3

Boost 1.44.0 - June, 2010 - Internationalization via single class path. More uniform error handling.

Peter Dimov suggested use of a single path class rather than a basic_path class template. That idea was the basis for the Version 3 redesign.

Thanks for comments from Robert Stewart, Zach Laine, Peter Dimov, Gregory Peele, Scott McMurray, John Bytheway, Jeff Flinn, Jeffery Bosboom.

Version 2

Boost 1.34.0 - May, 2007 - Internationalization via basic_path template.

So many people have contributed comments and bug reports that it isn't any longer possible to acknowledge them individually. That said, Peter Dimov and Rob Stewart need to be specially thanked for their many constructive criticisms and suggestions. Terence Wilson and Chris Frey contributed timing programs which helped illuminate performance issues.

Version 1

Boost 1.30.0 - March, 2003 - Initial official Boost release.

The Filesystem Library was designed and implemented by Beman Dawes. The original directory_iterator and filesystem_error classes were based on prior work from Dietmar Kühl, as modified by Jan Langer. Thomas Witt was a particular help in later stages of initial development. Peter Dimov and Rob Stewart made many useful suggestions and comments over a long period of time. Howard Hinnant helped with internationalization issues.

Key design requirements and design realities were developed during extensive discussions on the Boost mailing list, followed by comments on the initial implementation. Numerous helpful comments were then received during the Formal Review. Participants included Aaron Brashears, Alan Bellingham, Aleksey Gurtovoy, Alex Rosenberg, Alisdair Meredith, Andy Glew, Anthony Williams, Baptiste Lepilleur, Beman Dawes, Bill Kempf, Bill Seymour, Carl Daniel, Chris Little, Chuck Allison, Craig Henderson, Dan Nuffer, Dan'l Miller, Daniel Frey, Darin Adler, David Abrahams, David Held, Davlet Panech, Dietmar Kühl, Douglas Gregor, Dylan Nicholson, Ed Brey, Eric Jensen, Eric Woodruff, Fedder Skovgaard, Gary Powell, Gennaro Prota, Geoff Leyland, George Heintzelman, Giovanni Bajo, Glen Knowles, Hillel Sims, Howard Hinnant, Jaap Suter, James Dennett, Jan Langer, Jani Kajala, Jason Stewart, Jeff Garland, Jens Maurer, Jesse Jones, Jim Hyslop, Joel de Guzman, Joel Young, John Levon, John Maddock, John Williston, Jonathan Caves, Jonathan Biggar, Jurko, Justus Schwartz, Keith Burton, Ken Hagen, Kostya Altukhov, Mark Rodgers, Martin Schuerch, Matt Austern, Matthias Troyer, Mattias Flodin, Michiel Salters, Mickael Pointier, Misha Bergal, Neal Becker, Noel Yap, Parksie, Patrick Hartling, Pavel Vozenilek, Pete Becker, Peter Dimov, Rainer Deyke, Rene Rivera, Rob Lievaart, Rob Stewart, Ron Garcia, Ross Smith, Sashan, Steve Robbins, Thomas Witt, Tom Harris, Toon Knapen, Victor Wagner, Vincent Finn, Vladimir Prus, and Yitzhak Sapir.

A lengthy discussion on the C++ committee's library reflector illuminated the "illusion of portability" problem, particularly in postings by PJ Plauger and Pete Becker.

Walter Landry provided much help illuminating symbolic link use cases for version 1.31.0. 


© Copyright Beman Dawes, 2002-2005

© Copyright Andrey Semashev, 2021

Use, modification, and distribution are subject to the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt