On DragonFly BSD 6.4.0, std::locale("") fails unless LANG is set to some
locale that is supported in libc.
On Solaris 11.4, std::locale("") fails even if LANG is set correctly in
the environment. Recent versions of Solaris seem to have transitioned
to UTF-8 for filename encoding.
All BSD systems seem to have come to UTF-8 for path encoding by default,
so use utf8_codecvt_facet on all of them, plus Solaris.
Removed duplication of preprocessor checks for whether to use
utf8_codecvt_facet.
Check that BOOST_FILESYSTEM_POSIX/WINDOWS_API and BOOST_POSIX/WINDOWS_API
are defined in the same way and error out if not. Allow users to suppress
this check (and keep their code compiling) by defining
BOOST_FILESYSTEM_ALLOW_SYSTEM_API_MISMATCH to 1 to reduce the error to
a warning or to 2 to completely disable the check.
If we diverge in platform API selection with Boost.System again, we may
want to implement our own system category that is guaranteed to be in sync
with the platform API Boost.Filesystem actually uses. But for now the two
libraries are expected to be in sync, and the added check should do.
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.
This only affects POSIX platforms not supporting openat & co.
When the underlying directory iterator does not produce symlink status
during iteration, and the iterator points to a dangling symlink, the
recursive_directory_iterator increment would attempt to refresh file
statuses in the directory_entry. This would fail because the refresh
would query status in addition to symlink_status. This error was
wrongly reported to the caller if following symlinks was disabled for
the recursive iterator.
Fix this by only querying symlink_status. status is checked later,
if the iterator is configured to follow symlinks.
Because Boost.System has switched to define BOOST_POSIX_API on Cygwin[1],
Boost.Filesystem now defines its own set of macros for platform API
selection. At this time, we preserve the previous behavior, where
Cygwin is treated as Windows.
[1]: https://github.com/boostorg/system/pull/137
This error code is reported to be returned by
GetFileInformationByHandleEx(FileIdExtdDirectoryRestartInfo) in case of
Samba 3.0.2 share accessed from a Windows Server 2019 client, when
RequireSecuritySignature is set to 1 on the client. In the same setup,
GetFileInformationByHandleEx(FileBothDirectoryInformation) is reported
to succeed.
This doesn't seem to reproduce with Samba 4.19 server and Windows 10
client, so it may be specific to the client and server versions, or it
may be something else in the user's setup.
Add NTE_BAD_SIGNATURE to the list of errors on which we non-permanently
downgrade directory_iterator implementation to an older method.
Closes https://github.com/boostorg/filesystem/issues/334.
This forces the non-templated overloads accepting path to be chosen instead
of the templated members that expect arguments converible to Source.
This resolves overload resolution ambiguities, when the argument of a
user-defined type is convertible to path and multiple other types that qualify
as Source. By preferring the conversion to path we avoid testing other
conversion paths that may be ambiguous.
Fixes https://github.com/boostorg/filesystem/issues/326.
This moves the common part of v3 and v4 canonical() to a separate
function and changes the Windows implementation to use
GetFinalPathNameByHandleW system call. As a side effect, this converts
drive names to upper case, which makes paths more interoperable.
Additionally, on POSIX systems, avoid adding a trailing directory
separator if the input path has one (which may be the case in v4). This
is consistent with libstdc++ and MSVC implementations of std::filesystem.
Fixes https://github.com/boostorg/filesystem/issues/325.
When weakly_canonical was called with a relative input path, the operation
would test path elements for existence, which meant resolving them relative
to the current path instead of the base path specified in the call. To
mitigate this, make the source path absolute using the specified base path.
As a side effect, this fixes incorrect path produced on Windows if the
input path started with "..". The algorithm was unable to remove the last
element of the head path because there was none. As a result, the remaining
elements of the input path were appended to the full base path by canonical.
Fixes to https://github.com/boostorg/filesystem/issues/311.
This makes directory_entry::status, directory_entry::symlink_status, as well
as related methods behave similarly to the equivalent standalone operations.
std::filesystem specification for directory_entry::refresh doesn't explicitly
say that the file not existing is not an error, but it does say that
directory_entry::status and directory_entry::symlink_status should behave
the same way as the standalone operations. Currently, libstdc++, libc++
and MSVC standard library all avoid throwing the exception from
directory_entry::refresh if the file doesn't exist.
Closes https://github.com/boostorg/filesystem/issues/314.
GetFileAttributesExW that was used to implement file_size and is_empty
on Windows returns information about the symlink rather than the file
the symlink refers to. Fix this by opening the file and using
GetFileInformationByHandle to obtain the file size and attributes.
Additionally, reworked is_empty implementation to reuse the file handle
(and fd on POSIX systems) to create the directory iterator if the
operation is invoked on a directory. On POSIX systems, implement a
more lightweight version of is_empty_directory when readdir is safe
to use. Reusing the file handle/fd improves protection against
filesystem races, when the file that is being tested by is_empty
is initially a directory and then, when we create a directory
iterator, it is not.
Fixes https://github.com/boostorg/filesystem/issues/313.
This partly restores documentation removed in
5df060e95c and moves the features from
"deprecated" table to a new "removed" table. This provides users
with suggested replacements for the removed features.
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.
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.
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.
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.
This fixes hard compilation error when the passed type is not an iterator
at all. As a result, path constructors from iterators are no longer
selected by the compiler in overload resolution in users' code, when
the caller is passing an initializer list with a pair of non-iterator
elements. Added a test for this fix.
Also, use integral_constant to implement boolean type traits.
Fixes https://github.com/boostorg/filesystem/issues/287.
Path comparison operators that accept arbitrary path source types now require
the other argument to be exactly path. This prevents the compiler from picking
those operators when the other argument is convertible to path. This can happen
even when neither of the arguments are actually paths, e.g. when the
comparison operators are brought into the current scope by a using directive.
Fixes https://github.com/boostorg/filesystem/issues/285.
GetFileInformationByHandleEx with information classes that produce FILE_ID_128
fail with a special error code ERROR_INVALID_LEVEL when the filesystem is
SMBv1. Treat this error code the same as ERROR_INVALID_PARAMETER.
Fixes https://github.com/boostorg/filesystem/issues/284.
If the file handle for a directory in a SMBv1 share was opened with
FILE_READ_ATTRIBUTES access mode, GetFileInformationByHandleEx with
FileAttributeTagInfo returns FILE_ATTRIBUTE_NORMAL in the attributes, which
affected status, symlink_status and everything depending on those.
Work around this Windows bug by adding FILE_READ_EA everywhere where we need
attributes to be correct.
Also, use GENERIC_READ access mode when we call GetFileTime on the handle
afterwards. GetFileTime documentation explicitly mentions that GENERIC_READ
is required for it.
Fixes https://github.com/boostorg/filesystem/issues/282.
