[filesystem] create_directories fails on exFat formatted disk under Windows
Using an exFat formatted disk with Windows. Start with a path: e:\tmp Call filesystem::create_directories("e:\\tmp\\boost") This should succeed, creating the boost folder in e:\tmp. It fails with boost 1.79.0. It tries to create e:\tmp which already exists. In boost 1.78.0 this works as expected. I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks. Chris.
On 5/12/22 11:33, Chris Trueman via Boost wrote:
Using an exFat formatted disk with Windows.
Start with a path:
e:\tmp
Call filesystem::create_directories("e:\\tmp\\boost")
This should succeed, creating the boost folder in e:\tmp.
It fails with boost 1.79.0. It tries to create e:\tmp which already exists.
In boost 1.78.0 this works as expected.
I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks.
Can you tell what error code GetFileInformationByHandleEx returns? Also, can you test if the other path using GetFileInformationByHandle works on this filesystem? PS: You can report problems on GitHub: https://github.com/boostorg/filesystem/issues
On Thu, 12 May 2022 at 13:11, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 5/12/22 11:33, Chris Trueman via Boost wrote:
Using an exFat formatted disk with Windows.
Start with a path:
e:\tmp
Call filesystem::create_directories("e:\\tmp\\boost")
This should succeed, creating the boost folder in e:\tmp.
It fails with boost 1.79.0. It tries to create e:\tmp which already exists.
In boost 1.78.0 this works as expected.
I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks.
Can you tell what error code GetFileInformationByHandleEx returns? Also, can you test if the other path using GetFileInformationByHandle works on this filesystem?
After GetFileInformationByHandleEx fails, call GetLastError and see if result is INVALID_ERROR_PARAMETER. At this point you know (a) the path element exists (else we'd have returned earlier because h.handle == INVALID_HANDLE_VALUE) and (b) we can't have a reparse point so we should fall back on GetFileInformationByHandle to get the dwFileAttributes to determine if the path element is a directory or file. This is the change I've made locally to get 1.79.0 to work for me. In the current code, the only way the branch that calls GetFileInformationByHandle is used is if we're running on a version of Windows that doesn't support GetFileInformationByHandleEx. Chris.
participants (2)
-
Andrey Semashev
-
Chris Trueman