This is a header-only single-file std::filesystem
compatible helper library,
based on the C++17 and C++20 specs, but implemented for C++11, C++14, C++17 or C++20
(tightly following the C++17 standard with very few documented exceptions). It is currently tested on
macOS 10.12/10.14/10.15/11.6, Windows 10, Ubuntu 18.04, Ubuntu 20.04, CentOS 7, CentOS 8, FreeBSD 12,
Alpine ARM/ARM64 Linux and Solaris 10 but should work on other systems too, as long as you have
at least a C++11 compatible compiler. It should work with Android NDK, Emscripten and I even
had reports of it being used on iOS (within sandboxing constraints) and with v1.5.6 there
is experimental support for QNX. The support of Android NDK, Emscripten, QNX, and since 1.5.14
GNU/Hurd and Haiku is not backed up by automated testing but PRs and bug reports are welcome
for those too and they are reported to work.
It is of course in its own namespace ghc::filesystem
to not interfere with a regular std::filesystem
should you use it in a mixed C++17 environment (which is possible).
Test coverage is well above 90%, and starting with v1.3.6 and in v1.5.0 more time was invested in benchmarking and optimizing parts of the library. I'll try to continue to optimize some parts and refactor others, striving to improve it as long as it doesn't introduce additional C++17/C++20 compatibility issues. Feedback is always welcome. Simply open an issue if you see something missing or wrong or not behaving as expected and I'll comment.
I'm often in need of filesystem functionality, mostly fs::path
, but directory
access too, and when beginning to use C++11, I used that language update
to try to reduce my third-party dependencies. I could drop most of what
I used, but still missed some stuff that I started implementing for the
fun of it. Originally I based these helpers on my own coding- and naming
conventions. When C++17 was finalized, I wanted to use that interface,
but it took a while, to push myself to convert my classes.
The implementation is closely based on chapter 30.10 from the C++17 standard
and a draft close to that version is
Working Draft N4687.
It is from after the standardization of C++17 but it contains the latest filesystem
interface changes compared to the
Working Draft N4659.
Staring with v1.4.0, when compiled using C++20, it adapts to the changes according to path sorting order
and std::u8string
handling from Working Draft N4860.
I want to thank the people working on improving C++, I really liked how the language evolved with C++11 and the following standards. Keep on the good work!
If you ask yourself, what ghc
is standing for, it is simply
gulraks helper classes
, yeah, I know, not very imaginative, but I wanted a
short namespace and I use it in some of my private classes (so it has nothing
to do with Haskell, sorry for the name clash).
ghc::filesystem
is developed on macOS but CI tested on macOS, Windows,
various Linux Distributions, FreeBSD and starting with v1.5.12 on Solaris.
It should work on any of these with a C++11-capable compiler. Also there are some
checks to hopefully better work on Android, but as I currently don't test with the
Android NDK, I wouldn't call it a supported platform yet, same is valid for using
it with Emscripten. It is now part of the detected platforms, I fixed the obvious
issues and ran some tests with it, so it should be fine. All in all, I don't see it
replacing std::filesystem
where full C++17 or C++20 is available, it doesn't try
to be a "better" std::filesystem
, just an almost drop-in if you can't use it
(with the exception of the UTF-8 preference).
ℹ️ Important: This implementation is following the "UTF-8 Everywhere" philosophy in that all
std::string
instances will be interpreted the same as std::u8string
encoding
wise and as being in UTF-8. The std::u16string
will be seen as UTF-16. See Differences in API
for more information.
Unit tests are currently run with:
The header comes with a set of unit-tests and uses CMake as a build tool and Catch2 as test framework. All tests are registered with in CMake, so the ctest commando can be used to run the tests.
All tests against this implementation should succeed, depending on your environment it might be that there are some warnings, e.g. if you have no rights to create Symlinks on Windows or at least the test thinks so, but these are just informative.
To build the tests from inside the project directory under macOS or Linux just:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ctest
This generates the test binaries that run the tests and the last command executes them.
If the default compiler is a GCC 8 or newer, or Clang 7 or newer, it
additionally tries to build a version of the test binary compiled against GCCs/Clangs
std::filesystem
implementation, named std_filesystem_test
as an additional test of conformance. Ideally all tests should compile and
succeed with all filesystem implementations, but in reality, there are
some differences in behavior, sometimes due to room for interpretation in
in the standard, and there might be issues in these implementations too.
The latest release version is v1.5.14 and source archives can be found here.
The latest pre-native-backend version is v1.4.0 and source archives can be found here.
The latest pre-C++20-support release version is v1.3.10 and source archives can be found here.
Currently only the latest minor release version receives bugfixes, so if possible, you should use the latest release.
As ghc::filesystem
is at first a header-only library, it should be enough to copy the header
or the include/ghc
directory into your project folder or point your include path to this place and
simply include the filesystem.hpp
header (or ghc/filesystem.hpp
if you use the subdirectory).
Everything is in the namespace ghc::filesystem
, so one way to use it only as
a fallback could be:
#if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
#if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
#define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
#ifdef __APPLE__
#include <Availability.h>
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
#if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500 \
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000 \
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000 \
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
#undef GHC_USE_STD_FS
#endif
#endif
#endif
#endif
#ifdef GHC_USE_STD_FS
#include <filesystem>
namespace fs = std::filesystem;
#else
#include "filesystem.hpp"
namespace fs = ghc::filesystem;
#endif
If you want to also use the fstream
wrapper with path
support as fallback,
you might use:
#if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
#if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
#define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
#ifdef __APPLE__
#include <Availability.h>
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
#if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500 \
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000 \
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000 \
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
#undef GHC_USE_STD_FS
#endif
#endif
#endif
#endif
#ifdef GHC_USE_STD_FS
#include <filesystem>
namespace fs {
using namespace std::filesystem;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
#else
#include "filesystem.hpp"
namespace fs {
using namespace ghc::filesystem;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
#endif
Now you have e.g. fs::ofstream out(somePath);
and it is either the wrapper or
the C++17 std::ofstream
.
ℹ️ Be aware, as a header-only library, it is not hiding the fact, that it
uses system includes, so they "pollute" your global namespace. Use the
forwarding-/implementation-header based approach (see below) to avoid this.
For Windows it needs Windows.h
and it might be a good idea to define
WIN32_LEAN_AND_MEAN
or NOMINMAX
prior to including filesystem.hpp
or
fs_std.hpp
headers to reduce pollution of your global namespace and compile
time. They are not defined by ghc::filesystem
to allow combination with contexts
where the full Windows.h
is needed, e.g. for UI elements.
ℹ️ Hint: There is an additional header named ghc/fs_std.hpp
that implements this
dynamic selection of a filesystem implementation, that you can include
instead of ghc/filesystem.hpp
when you want std::filesystem
where
available and ghc::filesystem
where not.
Alternatively, starting from v1.1.0 ghc::filesystem
can also be used by
including one of two additional wrapper headers. These allow to include
a forwarded version in most places (ghc/fs_fwd.hpp
) while hiding the
implementation details in a single cpp file that includes ghc/fs_impl.hpp
to
implement the needed code. Using ghc::filesystem
this way makes sure
system includes are only visible from inside the cpp file, all other places are clean.
Be aware, that it is currently not supported to hide the implementation into a Windows-DLL, as a DLL interface with C++ standard templates in interfaces is a different beast. If someone is willing to give it a try, I might integrate a PR but currently working on that myself is not a priority.
If you use the forwarding/implementation approach, you can still use the dynamic switching like this:
#if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
#if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
#define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
#ifdef __APPLE__
#include <Availability.h>
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
#if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500 \
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000 \
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000 \
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
#undef GHC_USE_STD_FS
#endif
#endif
#endif
#endif
#ifdef GHC_USE_STD_FS
#include <filesystem>
namespace fs {
using namespace std::filesystem;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
#else
#include "fs_fwd.hpp"
namespace fs {
using namespace ghc::filesystem;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
#endif
and in the implementation hiding cpp, you might use (before any include that includes ghc/fs_fwd.hpp
to take precedence:
#if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
#if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
#define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
#ifdef __APPLE__
#include <Availability.h>
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
#if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500 \
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000 \
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000 \
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
#undef GHC_USE_STD_FS
#endif
#endif
#endif
#endif
#ifndef GHC_USE_STD_FS
#include "fs_impl.hpp"
#endif
ℹ️ Hint: There are additional helper headers, named ghc/fs_std_fwd.hpp
and
ghc/fs_std_impl.hpp
that use this technique, so you can simply include them
if you want to dynamically select the filesystem implementation.
Starting from v1.1.0, it is possible to add ghc::filesystem
as a git submodule, add the directory to your CMakeLists.txt
with
add_subdirectory()
and then simply use target_link_libraries(your-target ghc_filesystem)
to ensure correct include path that allow #include <ghc/filesystem.hpp>
to work.
The CMakeLists.txt
offers a few options to customize its behavior:
GHC_FILESYSTEM_BUILD_TESTING
- Compile tests, default is OFF
when used asON
.GHC_FILESYSTEM_BUILD_EXAMPLES
- Compile the examples, default is OFF
when used asON
.GHC_FILESYSTEM_WITH_INSTALL
- Add install target to build, default is OFF
when used asON
.GHC_FILESYSTEM_BUILD_STD_TESTING
- Compile std_filesystem_test
, the variant ofstd::filesystem
, defaulting to GHC_FILESYSTEM_BUILD_TESTING
.GHC_FILESYSTEM_TEST_COMPILE_FEATURES
can be set to a list of features to overrideCMAKE_CXX_COMPILE_FEATURES
when the detection of C++17 or C++20 for additional testscxx_std_20
to enforce building a filesystem_test_cpp20
with C++20).Please use hedronvision/bazel-cc-filesystem-backport, which will automatically set everything up for you.
There is a version macro GHC_FILESYSTEM_VERSION
defined in case future changes
might make it needed to react on the version, but I don't plan to break anything.
It's the version as decimal number (major * 10000 + minor * 100 + patch)
.
ℹ️ Note: Only even patch versions will be used for releases and odd patch version will only be used for in between commits while working on the next version.
There is almost no documentation in this release, as any std::filesystem
documentation would work, besides the few differences explained in the next
section. So you might head over to https://en.cppreference.com/w/cpp/filesystem
for a description of the components of this library.
When compiling with C++11, C++14 or C++17, the API is following the C++17
standard, where possible, with the exception that std::string_view
parameters
are only supported on C++17. When Compiling with C++20, ghc::filesysytem
defaults to the C++20 API, with the char8_t
and std::u8string
interfaces
and the deprecated fs::u8path
factory method.
ℹ️ Note: If the C++17 API should be enforced even in C++20 mode,
use the define GHC_FILESYSTEM_ENFORCE_CPP17_API
.
Even then it is possible to create fws::path
from std::u8string
but
fs::path::u8string()
and fs::path::generic_u8string()
return normal
UTF-8 encoded std::string
instances, so code written for C++17 could
still work with ghc::filesystem
when compiled with C++20.
The only additions to the standard are documented here:
ghc::filesystem::ifstream
, ghc::filesystem::ofstream
, ghc::filesystem::fstream
These are simple wrappers around std::ifstream
, std::ofstream
and std::fstream
.
They simply add an open()
method and a constructor with an ghc::filesystem::path
argument as the fstream
variants in C++17 have them.
ghc::filesystem::u8arguments
This is a helper class that currently checks for UTF-8 encoding on non-Windows platforms but on Windows it fetches the command line arguments as Unicode strings from the OS with
::CommandLineToArgvW(::GetCommandLineW(), &argc)
and then converts them to UTF-8, and replaces argc
and argv
. It is a guard-like
class that reverts its changes when going out of scope.
So basic usage is:
namespace fs = ghc::filesystem;
int main(int argc, char* argv[])
{
fs::u8arguments u8guard(argc, argv);
if(!u8guard.valid()) {
std::cerr << "Bad encoding, needs UTF-8." << std::endl;
exit(EXIT_FAILURE);
}
// now use argc/argv as usual, they have utf-8 encoding on windows
// ...
return 0;
}
That way argv
is UTF-8 encoded as long as the scope from main
is valid.
Note: On macOS, while debugging under Xcode the code currently will return
false
as Xcode starts the application with US-ASCII
as encoding, no matter what
encoding is actually used and even setting LC_ALL
in the product scheme doesn't
change anything. I still need to investigate this.
As this implementation is based on existing code from my private helper classes, it derived some constraints of it. Starting from v1.5.0 most of the differences between this and the standard C++17/C++20 API where removed.
This implementation has switchable behavior for the LWG defects
#2682,
#2935,
#2936 and
#2937.
The currently selected behavior (starting from v1.4.0) is following
#2682, #2936,
#2937 but
not following #2935,
as I feel it is a bug to report no error on a create_directory()
or create_directories()
where a regular file of the same name prohibits the creation of a directory and forces
the user of those functions to double-check via fs::is_directory
if it really worked.
The more intuitive approach to directory creation of treating a file with that name as an
error is also advocated by the newer paper
WG21 P1164R0, the revision
P1161R1 was agreed upon on Kona 2019 meeting see merge
and GCC by now switched to following its proposal
(GCC #86910).
// methods in ghc::filesystem::path:
path& operator+=(basic_string_view<value_type> x);
int compare(basic_string_view<value_type> s) const;
These are not implemented under C++11 and C++14, as there is no
std::basic_string_view
available and I did want to keep this
implementation self-contained and not write a full C++17-upgrade for
C++11/14. Starting with v1.1.0 these are supported when compiling
ghc::filesystem
under C++17 of C++20.
Starting with v1.5.2 ghc::filesystem
will try to allow the use of
std::experimental::basic_string_view
where it detects is availability.
Additionally if you have a basic_string_view
compatible c++11
implementation it can be used instead of std::basic_string_view
by defining GHC_HAS_CUSTOM_STRING_VIEW
and importing the
implementation into the ghc::filesystem
namespace with:
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}
before including the filesystem header.
To not depend on any external third party libraries and still stay portable and
compact, this implementation is following the "UTF-8 Everywhere" philosophy in that all
std::string
instances will be interpreted the same as std::u8string
encoding
wise and as being in UTF-8. The std::u16string
will be seen as UTF-16 and std::u32string
will be
seen as Unicode codepoints. Depending on the size of std::wstring
characters, it will handle
std::wstring
as being UTF-16 (e.g. Windows) or char32_t
Unicode codepoints
(currently all other platforms).
Starting with v1.5.0 ghc::filesystem
is following the C++17 standard in
using wchar_t
and std::wstring
on Windows as the types internally used
for path representation. It is still possible to get the old behavior by defining
GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE
and get filesystem::path::string_type
as
std::string
and filesystem::path::value_type
as wchar_t
.
If you need to call some Windows API, with v1.5.0 and above, simply
use the W-variant of the Windows-API call (e.g. GetFileAttributesW(p.c_str())
).
ℹ️ Note: When using the old behavior by defining
GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE
, use the path::wstring()
member
(e.g. GetFileAttributesW(p.wstring().c_str())
). This gives you the
Unicode variant independent of the UNICODE
macro and makes sharing code
between Windows, Linux and macOS easier and works with std::filesystem
and
ghc::filesystem
.
std::string path::u8string() const;
std::string path::generic_u8string() const;
vs.
std::u8string path::u8string() const;
std::u8string path::generic_u8string() const;
The return type of these two methods is depending on the used C++ standard
and if GHC_FILESYSTEM_ENFORCE_CPP17_API
is defined. On C++11, C++14 and
C++17 or when GHC_FILESYSTEM_ENFORCE_CPP17_API
is defined, the return
type is std::string
, and on C++20 without the define it is std::u8string
.
I created a wiki entry about quite a lot of behavioral differences
between different std::filesystem
implementations that could result in a
mention here, but this readme only tries to address the design choice
differences between ghc::filesystem
and those. I try to update the wiki page
from time to time.
Any additional observations are welcome!
Since v1.5.0 the complete inner mechanics of this implementations fs::path
where changed to the native format as the internal representation.
Creating any mixed slash fs::path
object under Windows (e.g. with "C:\foo/bar"
)
will lead clean path with "C:\foo\bar"
via native()
and "C:/foo/bar"
via
generic_string()
API. On all platforms redundant additional separators are
removed, even if this is not enforced by the standard and other implementations
mostly not do this.
Additionally this implementation follows the standards suggestion to handle
posix paths of the form "//host/path"
and USC path on windows also as having
a root-name (e.g. "//host"
). The GCC implementation didn't choose to do that
while testing on Ubuntu 18.04 and macOS with GCC 8.1.0 or Clang 7.0.0. This difference
will show as warnings under std::filesystem
. This leads to a change in the
algorithm described in the standard for operator/=(path& p)
where any path
p
with p.is_absolute()
will degrade to an assignment, while this implementation
has the exception where *this == *this.root_name()
and p == preferred_separator
a normal append will be done, to allow:
fs::path p1 = "//host/foo/bar/file.txt";
fs::path p2;
for (auto p : p1) p2 /= p;
ASSERT(p1 == p2);
For all non-host-leading paths the behavior will match the one described by the standard.
As symbolic links on Windows, while being supported more or less since Windows Vista (with some strict security constraints) and fully since some earlier build of Windows 10, when "Developer Mode" is activated, are at time of writing (2018) rarely used, still they are supported wiit th this implementation.
The Windows ACL permission feature translates badly to the POSIX permission
bit mask used in the interface of C++17 filesystem. The permissions returned
in the file_status
are therefore currently synthesized for the user
-level
and copied to the group
- and other
-level. There is still some potential
for more interaction with the Windows permission system, but currently setting
or reading permissions with this implementation will most certainly not lead
to the expected behavior.
extension()
did return non empty result for the directory name".."
ghcFilesystem::ghc_filesystem
is now set unconditionallystem()
, filename()
and extension()
of fs::path
would return wrongfs::last_write_time(path, time, ec)
setter on iOS, tvOS and watchOSfs::directory_entry::refresh()
now, consistently with status()
will notfile_type::not_found
as the typeEINTR
fs::copy_file()
fs::copy_file()
ignoring the skip_existing
option.GHC_NO_DIRENT_D_TYPE
on systems that don't support dirent::d_type
andPATH_MAX
, one is defined.fs::remove_all
nowfs::space
where a numerical overflow could happen in a multiplication.fs::create_directories
on Windows no longer breaks on long filenames.ghc::filesystem
treated mounted folder/volumes erroneously as symlinks,fs::canonical
to fail on paths containing those.recursive_directory_iterator
will not try to enter dead symlinks.fs::remove
failed when the path pointed to a read-only entry,std::fs
on windows.GHC_NO_DIRENT_D_TYPE
allows os detection to support systems withoutdirent.d_type
member, experimental first QNX compile support asstring_view
support when clang with libstdc++ is detected.<Availability.h>
<ghc/fs_std.hpp>
or <ghc/fs_std_fwd.hpp>
/<ghc/fs_std_impl.hpp>
.std::filesystem
recursive_directory_iterator
over large trees now somewhere betweenghc::filesystem
now has preliminary support for Cygwin. Changes whereGHC_FILESYSTEM_BUILD_STD_TESTING
to override additional build ofstd::filesystem
versions of the tests for comparison and the possibilityGHC_FILESYSTEM_TEST_COMPILE_FEATURES
to prefill the used compileCMAKE_CXX_COMPILE_FEATURES
when not given.directory_entry
creation leads to about 20%-25% in tests withrecursive_directory_iterator
over a larger directory tree.wchar_t
string_view
support makes use of <string_view>
or <experimental/string_view>
basic_string_view
implementationGHC_HAS_CUSTOM_STRING_VIEW
and importing the string viewghc::filesystem
namespace before including filesystem header.std::filesystem
tests now link-lrt
to avoid issues.fs::hard_link_count
failed due to the filesystems behavior,GHC_FS_API
and GHC_FS_API_CLASS
are now honored when whenmake install
files.GHC_FILESYSTEM_BUILD_TESTING
, GHC_FILESYSTEM_BUILD_EXAMPLES
GHC_FILESYSTEM_WITH_INSTALL
where implemented, prohibited setting themadd_subdirectory
, this fixfs::path
was originally created from thefs::path
on Windows, thatconst
methods.path
code to now store native path-representation. This changed awchar_t
as value_type
helped to avoidfs::path::native()
and fs::path::c_str()
can now be noexcept
as thewchar_t
is now the default for fs::path::value_type
andstd::wstring
is the default for fs::path::string_type
.const
methods of fs::path
is no longer an issueGHC_WIN_DISABLE_AUTO_PREFIXES
, for all other types of prefixesstd::filesystem::path
char
/std::string
based approach for Windows is stillGHC_WIN_DISABLE_WSTRING_STORAGE_TYPE
fs::file_status
operator==
introduced in std::filesystem
with C++20.fs::path::parent_path()
char8_t
and std::u8string
are supported where Source
is the parameter typefs::path::u8string()
and fs::path::generic_u8string()
now return a std::u8string
<=>
is now supported for fs::path
GHC_FILESYSTEM_ENFORCE_CPP17_API
ghc::filesystem
will fall backfs::path::u8string()
and fs::path::generic_u8string()
API if preferredfs::proximate(p, ec)
where the internal call to fs::current_path()
was noterror_code
variant, throwing possible exceptions instead of setting ec
.LWG_2936_BEHAVIOUR
is now on by default.Source
parameters that are string views.constexpr
.__MAC_OS_X_VERSION_MIN_REQUIRED
tostd::filesystem
is only selected on macOS if the deployment target isdirectory_iterator
recursive_directory_iterator
had an issue with the skip_permission_denied
_MSVC_LANG
is__cplusplus
, in the helping headers to/Zc:__cplusplus
is not used.false
on fs::exists
orfs::status
. Namespaced paths are not filtered anymore.TestAllocator
infilesystem_test.cpp
was completed to fulfill the requirements to build on CentOS 7 withdevtoolset-9
. CentOS 7 and CentOS 8 are now part of the CI builds.LWG_2936_BEHAVIOUR
fs::path::compare
behavior, where the comparison is as[fs.path.compare]
.wchar_t
versions ofstd::fstream
from ghc::filesystem::fstream
wrappers on Windows if using GCC with libc++.fs::directory_options::skip_permission_denied
ghc::filesystem
nowERROR_FILE_TOO_LARGE
fs::lexically_relative
fs::create_directories
true
when nothing needed to be created, because the directory already existed.error_code
fs::path
from a stream.timespec
fields to avoid warnings.ghc::filesystem
is re-licensed from BSD-3-Clause to MIT license. (seefs::rename
fs_fwd.hpp
or fs_std_fwd.hpp
there was a use ofDWORD
in the forwarding part leading to an error if Windows.h
was notDWORD
was removed.GetProcAddress
gave a warning with -Wcast-function-type
CMakeLists.txt
will automatically exclude building examples and tests whenghcFilesystemConfig.cmake
in${CMAKE_INSTALL_LIBDIR}/cmake/ghcFilesystem
for find_package
thatghcFilesystem::ghc_filesystem
.error: redundant redeclaration of 'constexpr' static data member
deprecationfs::create_directories
, thanks for the PR!GHC_FILESYSTEM_WITH_INSTALL
that isghc::filesystem
is used via add_subdirectory
.fs::path::lexically_normal()
that leaves a trailing separator..
as last element.BUILD_TESTING
andBUILD_EXAMPLES
to NO
, OFF
or FALSE
.std::string_view
whenstd::string_view
is available.fs::path::preferred_separator
declaration was not compiling on prefs::copy_options
where not forwarded from fs::copy
tofs::copy_file
in one of the cases.strerror_r
signatureghc::filesystem
missed a <vector>
includewchar_t/std::wstring
interface whenGHC_WIN_WSTRING_STRING_TYPE
, this isghc/fs_std*.hpp
header, to enhance compatibility.GHC_RAISE_UNICODE_ERRORS
(instead of replacing invalid code points orU+FFFD
).fs::copy_file
.readdir/readdir_r
code of fs::directory_iterator
;readdir_r
is now deprecated, I decided to drop it and the resultingstd::filesystem
fs::path::lexically_normal()
had some issues with ".."
-sequences.fs::recursive_directory_iterator
could run into endless loops,input_iterator_tag
conformance was broken, added testsstd::filesystem
builds of tests and examples for interoperabilityfs::weakly_canonical()
tests against std::fs
du
example showing the recursive_directory_iterator
fs::file_time_type
test helpersfs::copy()
now conforms LWG #2682, disallowing the use ofhpp
as extension to be marked as c++ and they where moved toinclude/ghc/
to be able to include by <ghc/filesystem.hpp>
as theghc::filesystem
now can be used as a submoduladd_subdirectory
and will export itself as ghc_filesystem
target_link_libraries(your-target ghc_filesystem)
#include <ghc/filesystem.hpp>
ghc::filesystem
declarations (fs_fwd.hpp
) and to wrap thefs_impl.hpp
)std::basic_string_view
variants of the fs::path
api areghc::filesystem::path::generic_string()
filesystem.h
was renamed filesystem.hpp
to better reflect that it isghc::filesystem::remove()
and ghc::filesystem::remove_all()
both areghc::filesystem::remove()
under Windows.ghc::filesystem::directory_iterator
now releasesend()
like the POSIX one does.ghc::filesystem::copy()
and ghc::filesystem::remove_all
fixed.ghc::filesystem::recursive_directory_iterator::difference_type
.-Wall -Wextra -Werror
and fixed resulting issues.fs.op.permissions
test to work with all tested std::filesystem
ghc::filesystem::u8arguments
as argv
converter, toargc
andargv
and it will fetch the Unicode version of the command line and convertexamples
folder with hopefully some usefull example usage. Examples areghc::filesystem
and C++17 std::filesystem
whenstd::filesystem
for comparison.fstream
include.timespec
/timeval
usage.chrono
conversion issues in test and example on clang 7.0.0.ghc::filesystem::canonical
now sees empty path as non-existant and reportsghc::filesystem::weakly_canonical
now returns relativeghc::filesystem::remove_all
now also counts directories removed (#2)recursive_directory_iterator
tests didn't respect equality domain issuesstd::filesystem
tests.noexcept
tagged methods and functions could indirectly throw exceptionsstd_filesystem_test
is now also generated if LLVM/clang 7.0.0 is found.This was the first public release version. It implements the full range of
C++17 std::filesystem
, as far as possible without other C++17 dependencies.