The "unused" attribute suppresses warnings emitted by clang for global
constants that are used to hook into early initialization of globals. The
"used" attribute is a precaution to ensure these hooks are not eliminated
by compiler or linker.
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.
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
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.
Filenames starting with a dot (and no other dots) are commonly treated
as filenames with no extension rather than an extension. This is also
the behavior mandated in C++17 filesystem.
Reported in https://github.com/boostorg/filesystem/issues/88.
The print name can be empty for some reparse points (e.g. mount points
created by Box cloud storage driver and directory junctions created by
junction.exe). It is supposed to be mostly used for presenting a "simple"
path to the user and not to actually locate the file.
The substitute name is the actionable replacement path, but it is in
NT path format and can potentially point to unmounted volumes and
UNC resources. The implementation attempts to convert the NT path
to Win32 path by matching commonly known patterns against the NT path.
If no pattern matches, we create a Win32 path by converting the NT path
prefix to "\\?\".
Related to https://github.com/boostorg/filesystem/issues/187.
The new implementation is also not relying on the root name format and
is more pertormant as it avoids unnecessarily copying path elements during
operation.
Note that this commit does not remove the trailing dot elements in the
normalized paths.
- Unified root name and root directory parsing that was scattered and
duplicated across different algorithms. The new implementation is
consolidated in a single function for parsing root name and root
directory, which is used from various algorithms.
- The new root name parsing now supports Windows local device ("\\.\")
and NT path ("\??\") prefixes. It also adds support for filesystem
("\\?\") prefix to some of the higher level algorithms that were
using custom parsing previously. Tests updated to verify these prefixes.
- Some of the path decomposition methods were unified with presence checking
methods (e.g. root_name with has_root_name). This makes these methods
work consistently and also makes the has_* methods less expensive as
they no longer have to construct a path only to check if it is empty.
- The filename accessor no longer returns root name if the whole path
only consists of a root name. This also affects stem and extension as
those accessors are based on filename. This is a breaking change.
- Cleaned up code:
- Removed redundant checks for std::wstring support.
- Added header/footer headers to globally disable compiler warnings.
- Removed commented out super-deprecated code.
- Added missing includes and removed includes that are not needed.
- Nonessential code formatting.
Avoid creating root directory path only to test if it's empty. Avoid
calling root_directory multiple times in root_path.
Also, nonessential code reformatting.
When current_path on POSIX falls back to the dynamically allocated
buffer for the resulting path, start with double the size of the
small stack buffer that was used initially.
When canonical() resolves symlink, it is possible that a symlink resolves
to an absolute path with a different root. We need to update the root
path so that when we restart symlink resolution the check for the
root path still works.
Also, slightly refactored the canonical() implementation to reduce code
size and possibly optimize the generated code.
There was a missing calling convention specification in the CopyFileEx
callback. This was not a problem in 64-bit builds since there is no
stdcall convention in 64-bit x86.
When CopyFileEx copies multi-stream files, the callback is executed for each
stream separately. Each stream is represented with a separate file handle,
so we have to flush buffers when the stream is fully copied, rather than the
whole file.
Use FlushFileBuffers to force any buffered data written to the permanent
storage. The previously used COPY_FILE_NO_BUFFERING flag only guarantees
that no data is left in the OS filesystem cache, but does not ensure
that any device buffers are flushed.
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.
The buffer size is now selected based on the file size and filesystem block
size and is limited with min and max. This allows to reduce memory consumption
and possibly increase performance when copying smaller files.
Some filesystems have regular files with generated content. Such files have
arbitrary size, including zero, but have actual content. Linux system calls
sendfile or copy_file_range will not copy contents of such files, so we must
use a read/write loop to handle them.
Check the type of the source filesystem before using sendfile or
copy_file_range and fallback to the read/write loop if it matches one of
the blacklisted filesystems: procfs, sysfs, tracefs or debugfs.
Also, added a test to verify that copy_file works on procfs.
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.
These options allow to synchronize the copied data and attributes with
the permanent storage. Note that by default on POSIX systems copy_file
used to synchronize data in previous releases, and this commit changes
this. The caller now has to explicitly request syncing, as it has
significant performance implications.
Closes https://github.com/boostorg/filesystem/issues/186.
At least HP-UX is known to leave the file descriptor open if close() returns
EINTR. On other systems (Linux, BSD, Solaris, AIX) the file descriptor
is closed in the same situation, and closing it again may potentially close
the wrong descriptor if it is reused by another thread. We introduce
close_fd internal helper to abstract away these platform differences.
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.
create_directories used to ignore errors returned by status()
calls issued internally. The operation would likely fail anyway,
but the error codes returned by create_directories would be incorrect.
Also, it is better to terminate the operation as early as possible
when an error is encountered.
Reported in https://github.com/boostorg/filesystem/issues/182.
This makes a difference in case if Boost.Filesystem is linked statically into
user's application. In this case filesystem_error used to be not marked as
publicly visible, which could make it impossible to catch the exception if
it crossed shared library boundary. By marking the class as publicly visible
we ensure that RTTI is always visible, even in static builds.
The exported members are also marked with dllexport/dllimport attributes
for compatibility with Windows.
Functions for stat/statx abstraction become unused when either of
the two APIs is used, which triggers clang warnings.
Ported copy_directory to statx and removed the BOOST_COPY_DIRECTORY
macro. One less usage of stat().
Removed workarounds for MSVC versions older than 7.0. Use portable
typedef for 64-bit integers.
Marked some internal functions inline. Removed zero initialization
of stat structs prior to stat calls, which is expected to initialize
the struct anyway.
The Linux statx system call allows to specify the data the caller is
interested in. This has the potential of improving performance
if some information is expensive to provide.
Also, changed hard_link_count to return static_cast<uintmax_t>(-1)
in case of errors. Changed file_size to report ENOSYS instead of
EPERM when the operation is invoked on a non-regular file.
This follows C++20 definition, which returns a minimum representable time
point value in case of error.
Also, slight refactoring of last_write_time setter function and a fix
to ensure the error code is cleared incase of success.
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.
The operation would use (symlink_)status internally to test if the target
file or directory exists. That operation can return an error code even if
it completes successfully. However, copy operation would abort in this case
before attempting to copy anything. This would not be caught by tests because
the tests use the overloads without an error code, and an exception is not
thrown by (symlink_)status in this case.
The fix is to test the returned file status and return if it indicates error.
Also, avoid using the external error code to receive error code from
(symlink_)status to keep it clean if copy operation succeeds.
A similar problem has been fixed in Windows implementation of space operation.
Fixes https://github.com/boostorg/filesystem/issues/152.
windows_file_codecvt is not exported from Boost.Filesystem and is
only used internally. It needs to be visible, where it matters
(which, given that this component is Windows-specific, is probably
nowhere).
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.
Use the common functions for indicating failure.
In POSIX version, check for EINTR error code when reading from
/dev/(u)random and return the appropriate error code.
On Windows, use the proper type for error code. Also, include
winapi/config.hpp to let Boost.WinAPI define targer Windows version
macros.
Use unsigned types for sizes and indexes.
WASI is a POSIX-like platform that has a few important differences:
* There is no concept of a mutable current directory.
* There is no concept of a file mode, and no `chmod` call.
* There is no concept of a filesystem, and no `statfs` call.
* There is no `readdir_r` call because there are no threads.
