Since the current and initial paths on Windows may have non-canonical
root paths (i.e. "c:\" instead of "C:\"), path comparisons may fail
because of the case differences between the canonicalized paths and
the expected paths. To avoid these spurious failures, canonicalize root
paths in all expected paths.
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.
* 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.
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.
copy_file_tests with copy_options::update_existing used to fail sometimes,
when the last modification timestamps on the test files were close enough.
Run the tests after a pause to make sure the timestamps are far enough apart.
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.
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.
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.
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.
v4 remove_filename works similar to std::filesystem, i.e. preserves
the trailing directory separator after removing the filename.
v3 remove_filename works as before. Its behavior is also useful in
v4, so added a new method remove_filename_and_trailing_separators
with the same behavior.
Also added replace_filename that was previously missing.
remove_filename discrepancy from std::filesystem was reported in:
https://github.com/boostorg/filesystem/issues/271
This causes ambiguities in users' code where the previously added conversion
from user-defined types that have a conversion to one of the path source
types:
struct my_class
{
operator std::string() const;
};
std::string to_string(std::string const&);
std::string to_string(boost::filesystem::path const&);
to_string(my_class());
The above call is ambiguous as the conversion operator in my_class and
a converting constructor in boost::filesystem::path from my_class are
both available and have equivalent ranks.
Removing the conversion constructors from boost::filesystem::path
means users will have to explicitly cast their types to one of the
path source types before constructing path.
In order to preserve backward compatibility with operator== and operator!=
for paths that also accepted source types (path::string_type,
const path::value_type*), we have to update path::compare and comparison
operators to accept types that are convertible to source types.
Fixes https://github.com/boostorg/filesystem/issues/273.
Path traits and relevant path members were reworked to better support
wider range of types that are compatible with path constructors, assignment
and appending members. Added support for C++17 std::string_view,
boost::string_view and boost::container::string as the possible string
types accepted by path members.
Also extended support for types convertible to one of the string types.
Previously, user's type had to be convertible to a string with a character
type that matches the native path character type. Now all supported character
types are acceptable.
Additionally, restricted members accepting a pair of iterators to only accept
iterators whose value types are one of the supported path character types.
Lastly, path::compare and comparison operators now only accept path arguments,
relying on path conversion constructors to do the job of supporting various
source types. Also removed noexcept from compare as it is using lex_compare
and iterators internally and those can throw.
Closes https://github.com/boostorg/filesystem/issues/208.
Users are advised to use string types and iterators instead of containers
to construct/assign/append to paths.
In v4, the support for containers is removed.
For some system files and folders like "System Volume Information"
CreateFileW fails with ERROR_ACCESS_DENIED while GetFileAttributesW
succeeds. GetFileAttributesW doesn't allow to discover whether the
file is a symlink or some other kind of a reparse point, so this
fallback will only work for files that are not reparse points,
symlinks or not. For reparse points continue to report error.
Closes https://github.com/boostorg/filesystem/issues/234.
Turns out string_file.hpp was tested in operations_unit_test, though not
included directly. Since string_file.hpp contents are disabled when the
test is compiled (as any other deprecated functionality), the test failed
to compile.
Moved the string_file.hpp test to deprecated_test, which explicitly enables
deprecated functionality. Also, include string_file.hpp in filesystem.hpp
if explicitly requested by defining BOOST_FILESYSTEM_DEPRECATED.
