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.
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.
This forces definition of _WIN32_WINNT by Boost.WinAPI, which is important
for CopyFileEx and related symbols to be defined. Platform SDK from MSVC-8
does not define the macro by default, which caused compilation errors
previously.
In single-threaded builds we can assume no thread synchronization
is necessary and avoid the dependency on Boost.Atomic. The dependency
caused single-threaded build failures because Boost.Atomic requires
multithreading to be enabled.
The CMake build currently does not support single-threaded builds, so
the dependency is left present there.
Closes https://github.com/boostorg/filesystem/issues/188.
Since sendfile and copy_file_range can fail for some filesystems
(e.g. eCryptFS), we have to fallback to the read/write loop in copy_file
implementation. Additionally, since we implement the fallback now,
fallback to sendfile if copy_file_range fails with EXDEV and use
copy_file_range on older kernels that don't implement it for
cross-filesystem copying. This may be beneficial if copy_file_range
is used within a filesystem, and is performed on a remote server NFS or CIFS).
Also, it was discovered that copy_file_range can also fail with EOPNOTSUPP
when it is performed on an NFSv4 filesystem and the remote server does
not support COPY operation. This happens on some patched kernels in RHEL/CentOS.
Lastly, to make sure the copy_file_data pointer is accessed atomically,
it is now declared as an atomic value. If std::atomic is unavailable,
Boost.Atomic is used.
Fixes https://github.com/boostorg/filesystem/issues/184.
By defining these new config macros the user can configure the library
to avoid using some system APIs even if they are detected as available
by the library build scripts. This can be useful in case if the API
is known to consistently fail at runtime on the target system.
Related to https://github.com/boostorg/filesystem/issues/172.
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.
This should fix readdir(_r) on 32-bit systems, which was not 64-bit after
commit c758552338 because _FILE_OFFSET_BITS=64
was not defined in directory.cpp. Also, there were filesystem-related system
calls in unique_path.cpp, where the macro was not defined either. Including
the platform header in all source files is useful for possible future changes
that may require the platform-specific macros.
Closes https://github.com/boostorg/filesystem/pull/150.
Directory iteration components were moved to separate files to simplify
maintenance of operations.hpp/cpp.
directory_iterator implementation on POSIX platforms has been reworked
to only allocate internal buffer when readdir_r is used. When readdir
is used, the dirent structure returned by readdir is used directly, which
eliminates the potential of buffer overrun in case if some directory name
exceeds the buffer size. This also removes the need to copy dirent members
into the buffer, which improves performance and simplifies maintenance.
For buffer size we now use the max path size as opposed to max filename
size. This is done to minimize the possibility of buffer overruns when
readdir_r is used.
On Windows, use Boost.WinAPI to configure the default target Windows version.
This removes WINVER and _WIN32_WINNT defines in Boost.Filesystem as these
macros should be defined by Boost.WinAPI now.
Additionally, exception.hpp and directory.hpp includes in operations.hpp are
marked as deprecated as operations.hpp do not need those components. Users
are encouraged to include the new headers explicitly in their code, as needed.
This simplifies maintenance of the operations.hpp/cpp files.
Also, moved BOOST_FILESYSTEM_SOURCE definition to the build system files
instead of defining it in every source file.
