Since we now require C++11 scoped enums and removed deprecated enums,
we can now pass copy_options and directory_options to the compiled
library without converting to the underlying type.
Removed APIs that were marked as deprecated a long time ago. Disabled
by default support for path construction, assignment and appending from
container types. Users can still enable this functionality by defining
BOOST_FILESYSTEM_DEPRECATED.
Updated docs, tests and examples accordingly.
Use nullptr, rvalue references, default function template parameters,
deleted/defaulted functions, noexcept, final, override and scoped enums.
Don't use constexpr yet, as it would raise MSVC requirement.
This follows the absolute() definition in the docs, as in v4 appending
an empty path results in a trailing slash.
Unfortunately, this also influences canonical and weakly_canonical,
so we had to duplicate those for v3 and v4 as well.
Fixes https://github.com/boostorg/filesystem/issues/301.
In v3, equivaluent would successfully return false if one of the paths
existed and the other one didn't. v4 now fails in this case, similar
to std::filesystem.
This reflects the actual implementation and effectively allows
canonical("") to work, which is essential for weakly_canonical("a/b"),
where "a" doesn't exist, to succeed.
Related to https://github.com/boostorg/filesystem/issues/300.
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.
If the input path is relative and none of its elements exist in the filesystem,
the head path calculated in weakly_canonical is empty. In this case, we still
need to call canonical on it to produce an absolute path (which will be
equivalent to the base path) and append the tail path to it.
Fixes https://github.com/boostorg/filesystem/issues/300.
std::filesystem::path::generic_string mandates that the returned string
uses *single* forward slashes for directory separators, which means
any duplicates must be removed. Boost.Filesystem now follows this definition,
and also documents that forward slashes are used for directory separators.
Additionally, since only directory separators are supposed to be affected,
in v4 avoid converting any slashes that are part of the path root name. This
is the case on Windows with UNC paths and Windows-specific path prefixes.
Keep v3 behavior unchanged for backward compatibility.
Closes https://github.com/boostorg/filesystem/issues/299.
Assume time_t is signed on Windows, which means negative values are
possible and represent dates before January 1, 1970 (which is also
allowed by FILETIME).
In order to increase the effective range of time_t, add/subtract
the offset value in seconds rather than in 100 ns units.
Perform range checks and report error if the input date/time, whether
in time_t or FILETIME, would cause an overflow during conversion.
Fixes https://github.com/boostorg/filesystem/issues/293.
Due to other Boost libraries that Boost.Filesystem depends on dropping
support for C++03, Boost.Filesystem now requires C++11 as a minimum.
Thus remove C++03 testing from CI and update docs accordingly.
Although concurrent modification of the input file during copy_file is
UB and not a supported use case, still avoid looping indefinitely in this
case. The fix applies to sendfile and copy_file_range implementations
of copy_file.
Related to https://github.com/boostorg/filesystem/issues/292.
GetFileTime is documented to require GENERIC_READ access right, but this causes
problems if the file is opened by another process without FILE_SHARE_READ.
In practice, FILE_READ_ATTRIBUTES works, and FILE_READ_EA is also added for
good measure, in case if it matters for SMBv1.
If this doesn't work in some case, we might switch to
GetFileInformationByHandle(Ex) in the future.
Fixes https://github.com/boostorg/filesystem/issues/290.
This overload takes filesystem::path as its first argument to support
wide character paths on Windows. Other than this, the overload is
equivalent to std::fopen.
After the recent change to get_reparse_point_tag_ioctl, status functions
should no longer throw if error reporting is done via error_code. This
allows us to mark all file status querying functions with error_code
arguments noexcept, as specified in std::filesystem and Boost.Filesystem
docs.
This commit changes behavior of directory_entry constructors and modifiers
that change the stored path in v4: the methods will now automatically query
the filesystem for the file status instead of leaving the cached data
default-initialized. This means that the paths passed to directory_entry
must be valid, otherwise an error will be returned. Filesystem querying
is implemented in the new directory_entry::refresh methods.
The constructors and modifiers that accepted file_status arguments are
now removed in v4. The cached file statuses are an implementation detail,
and eventually we may want to add more cached data, as we add more observers
to directory_entry.
Also added a few file type observers to directory_entry. These observers
allow to avoid querying the filesystem if the full file status is not cached
but the file type is (i.e. when permissions are not cached). This is the case
with readdir-based implementation of directory_iterator, if the underlying
C library supports dirent::d_type field.
recursive_directory_iterator has been updated to use the added file type
observers instead of querying the full status. This may improve performance
of directory iteration.
Closes https://github.com/boostorg/filesystem/issues/288.
