This follows other Boost libraries (in particular, Boost.System) in
treating Cygwin as a POSIX platform rather than Windows. This is
a breaking change, but apparently downstream Boost.Filesystem packages
on Cygwin are patched to the same effect.
As part of this change, AT_NO_AUTOMOUNT is made an optional requirement
to enable POSIX *at APIs. This flag is not POSIX-standard and is not
supported on Cygwin, while *at APIs are.
* Make the library modular usable.
* Use searched-lib targets for external/OS/Windows libraries to avoid trying to refer to mangled names for them. And hence failing to find them.
* Use the OS temp dir for creating test dir to avoid putting dirs in random location based on where one runs tests from.
* Switch to library requirements instead of source. As source puts extra source in install targets.
* Updated dependencies.
* Add missing NO_LIB usage requirements.
* Add missing import-search for cconfig/predef checks.
* Add requires-b2 check to top-level build file.
* Bump B2 require to 5.2
* Change all <source> references to <library>.
* Update copyright dates.
* Move inter-lib dependencies to a project variable and into the build targets.
* Split b2 dependencies into public and private.
* Undo temp dir for test change.
* Make winapi dep target-os specific. And remove direct atomic dep as it is already handled by conditional rule.
* Remove bug targets from all build as that's not a regular project.
Use Linux fallocate system call to preallocate storage for the target
file in copy_file backends based on sendfile and copy_file_range. These
backends are only used when the file size is known beforehand, and
preallocating storage allows to reduce filesystem fragmentation and
get an early error if there's not enough free space on the target
filesystem.
Preallocation is only done as an optimization/hint. On filesystems
that do not support it we continue the data copying process as before.
This is why we aren't using posix_fallocate, because glibc contains
an emulation path that is used when the filesystem doesn't support
the functionality. We don't want this emulation, as it would effectively
double the amount of written data.
The previous strategy of force-inlining methods that are dependent
on the library version is not effective with MSVC in debug mode,
when linking the static library. The compiler does not inline
methods despite the markup, and during linking the static library
with the user's module the linker may or may not pick up user's
definitions of these methods.
When building the library, do not define path methods that depend
on the library version. Instead, explicitly call v4 internal methods
throughout the implementation. This way the compiled library does not
contain v4 versions of these methods, and therefore does not conflict
with user's definitions of these methods.
Fixes https://github.com/boostorg/filesystem/issues/279.
The previous implementation could still allow for following symlinks
while remove_all is running if a directory was replaced with a symlink
higher in the tree than remove_all is currently processing. This was
reported here:
https://github.com/boostorg/filesystem/issues/224#issuecomment-1183738097
The solution is to use POSIX.1-2008 *at APIs to prevent symlink resolution
higher in the directory tree while iterating over the subtree in remove_all.
This required updating the directory iterator construction interface so that
it is possible to pass the base directory fd and return fd of the directory
used by the iterator. This is done via platform-specific params that are
currently defined only for POSIX. Additionally, status, symlink_status and
remove were extended to accept the base directory fd as well.
Other systems, including Windows, remain vulnerable.
Related to https://github.com/boostorg/filesystem/issues/224.
Even though the syscall number is defined in kernel headers, the syscall
is blacklisted by seccomp in runtime.
Note that Android 11 also introduces the libc wrapper for statx, so
effectively the library will always use the libc wrapper on Android.
Reported in https://github.com/boostorg/filesystem/issues/229.
Another process could replace the directory being processed by remove_all
with a symlink after remove_all called symlink_status but before
it creates a directory iterator. As a result, remove_all would remove
the linked directory contents instead of removing the symlink.
On POSIX systems that support fdopendir and O_NOFOLLOW flag for open(2),
this can be prevented by opening the directory with O_NOFOLLOW before
iterating. This will fail if the directory was replaced with a symlink.
No protection on other systems.
Reported in https://github.com/boostorg/filesystem/issues/224.
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.
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.
Auto-linking can still be useful to users of MSVC and compatible
compilers on Windows, when the user links against static build of
Boost.Filesystem. This feature is marked deprecated though, so
it can be removed in the future, when the generated CMake config
files include information about third-party dependencies of Boost
libraries.
Additionally, restored support for linking against Windows CE-cpecific
coredll library. This platform is not tested though and therefore not
properly supported.
Closes https://github.com/boostorg/filesystem/issues/156.
