Apparently, gcc wants the friend declaration of lex_compare_v3 to be annotated
with BOOST_FILESYSTEM_DECL, same as the previous declaration in the namespace
scope, and emits a -Wattributes warning otherwise.
Closes https://github.com/boostorg/filesystem/issues/213.
The contents is (a) language dependent and (b) is modified by some
standard libraries (e.g. libstdc++ and Dinkumware) and possibly OS,
which causes test failures on AppVeyor.
When the path ends with a non-root directory separator, no longer
produce a trailing dot element (filename). Instead, return an empty
path.
This affects not only path iterators and path::filename, but also any
other APIs that rely on them.
Closes https://github.com/boostorg/filesystem/issues/193.
The new implementation is prepared for the removal of the implicit
trailing dots in v4 path. It also no longer uses recursion
internally and therefore is better protected against stack overflows.
As a side effect of this rewrite, create_directories no longer reports
error if the input path consists entirely of dot and dot-dot elements.
This is in line with C++20 std::filesystem behavior.
One of the create_directories tests depends on the function failing
to create directories in the root directory. This normally fails
when the tests run under a normal user, but not when running as
root, which is the case when running GitHub Actions in a container.
linux/magic.h was introduced in Linux kernel 2.6.19, building Boost.Filesystem
with older kernel headers would fail because of this. Only include the header
when it is found and fallback to our local constant definitions when it's not.
Windows APIs such as GetFileAttributesW perform lexical path normalization
internally, which means e.g. "C:\a\.." resolves to an existing path
even if "C:\a" doesn't. This breaks depection of the longest sequence
of existing path elements in weakly_canonical and results in an error
in canonical that is called on that sequence.
As a workaround, perform forward iteration on Windows, so that we
stop on the first path element that doesn't exist.
Also, while at it, corrected error code reported from weakly_canonical
when status fails with an error.
Closes https://github.com/boostorg/filesystem/issues/201.
Apparently, gcc does not support the attribute on Mac OS 11.4. Since
we can't tell if other systems aren't supported as well, it's better
to check with a configure check. As a side effect, this might add
support for more compilers.
Closes https://github.com/boostorg/filesystem/issues/199.
This works around recurringissues when Boost.Filesystem is used during
program termination (for example, in Boost.Log, when it performs the final
log file rotation). At that point, the path locale as well as dot and dot-dot
paths may no longer be available.
Also, MSVC 14.2 has a bug[1] that results in a deadlock whet dot or
dot-dot path is being created during program termination, while atexit
callbacks are being run in the main thread. This change works around it
as the new code does not call atexit on initialization of these paths.
This is only supported on MSVC, GCC, Clang and compatible compilers that
support MSVC-specific or GCC-specific means to customize global initialization
order.
[1]: https://github.com/boostorg/log/issues/153
In order to avoid hardcoding library dependencies recursively for the
configure checks performed in CMake build scripts, we generate the list
of all include directories. If there is a unified Boost include tree,
we can use that and avoid filesystem scanning.
Instead of using atomic<> to access global function pointers, use raw
pointers and atomic_ref to access them safely in multi-threaded builds.
This allows to ensure constant initialization of the function pointers,
even in C++03. This also solves the problem of undefined dynamic
initialization order that we previously tried to solve with the
init_priority attribute. The attribute turns out to not work if the
pointers were raw pointers (in single-threaded builds). It is also
not supported by Intel Compiler and possibly other, which required
us to avoid using the function pointer for fill_random.
The resulting code should be simpler and more portable. In order to
check for C++20 std::atomic_ref availability, the older check for <atomic>
header was replaced with a check for std::atomic_ref. If not available,
we're using Boost.Atomic, as before.
Fall back to reading /dev/(u)random if getrandom fails with ENOSYS.
Also, extracted the portability macros for atomics to a separate header
to be able to use them in unique_path.cpp. Rearranged function pointers
initialization to decouple the initializer object from the particular
system calls.
For getrandom, the ENOSYS failure is only cached if the compiler supports
specifying global object initialization priority, which is needed to ensure
that the function pointer is initialized before the syscall initializer
in a different TU. If the compiler does not support this feature, just
always attempt getrandom first.
This can be useful if the syscall is present at compile time but fails with
ENOSYS at run time (for example, in Docker containers that restrict the syscall,
even if available on the host).
Additionally, marked statx syscall wrappers with attributes to disable MSAN
for them. It was reported that MSAN on clang 10 is showing errors
accessing uninitialized data in stx_mask, which must be initialized by the
syscall.
Related to https://github.com/boostorg/filesystem/issues/172
Related to https://github.com/boostorg/filesystem/issues/185
Boost.Filesystem v4 will contain breaking changes from v3 that are required
for better compatibility with C++17 std::filesystem. It will also remove
the deprecated features of v3.
Updated docs to reflect the differences between v3 and v4. Updated tests
to verify both v3 and v4 where the differences are present.
This is a breaking change.
path::filename accessor now only returns the actual filename or the implied
trailing dot element of the path, if it ends with a separator other than
root directory. This makes boost::filesystem::path behavior closer to that
of std::filesystem::path.
Updated tests and docs accordingly.
Closes https://github.com/boostorg/filesystem/issues/194.
If Windows is running in Developer mode, it is possible to specify
SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag to CreateSymbolicLinkW
so that the call doesn't require elevated privileges.
While at it, explicitly separated implementation of create_symlink and
create_directory_symlink for POSIX and Windows.
This doesn't compile with gcc 8 on MinGW-w64, and fails in runtime with
gcc 10.2 and clang 8.0.1 on Cygwin64 because character code conversion errors,
so basically std::filesystem never works with wide paths on Windows.
We still use wide paths as `const wchar_t*` with libc++ though.
Also, changed BOOST_FILESYSTEM_C_STR definition to accept the path as
an argument and use that definition in the tests rather than duplicating it.
Related to https://github.com/boostorg/filesystem/issues/181.
