filesystem
v1.5.14
ghc::filesystem::ifstream ， ghc::filesystem::ofstream ， ghc::filesystem::fstreamghc::filesystem::u8arguments這是一個僅基於C ++ 17和C ++ 20規格的僅標頭單文件std::filesystem兼容輔助庫庫，但針對C ++ 11，C ++ 14，C ++ 17或C ++ 20（遵循C ++ 17的緊密遵循C ++ 17，遵循C ++ 17的緊密記錄，很少有記錄的標準）。目前已在MACOS 10.12/10.14/10.15/11.6，Windows 10，Ubuntu 18.04，Ubuntu 20.04，Centos 7，Centos 7，Centos 8，FreeBSD 12，Alpine ARM/ARM64 Linux和Solaris 10中進行測試，但只要您至少可以使用C++Compatible Commible Commible Complible compitible Commible and Solaris 10。它應該與Android NDK，Emscripten和我什至有報導有關iOS上使用的報告（在沙盒限制內），並且與v1.5.6進行了對QNX的實驗支持。 Android NDK，Emscripten，QNX的支持，並且由於1.5.14 GNU/Hurd和Haiku並未得到自動測試的支持，但也歡迎提供PRS和BUG報告，並且據報導它們可以正常工作。當然，它在其自己的命名空間ghc::filesystem中不干擾常規的std::filesystem ，如果您在混合的C ++ 17環境中使用它（可能是可能的）。
測試覆蓋範圍遠高於90％，從v1.3.6開始，並在v1.5.0中投入了更多時間來進行基準測試和優化圖書館的某些部分。我將嘗試繼續優化某些零件和重構其他零件，只要不引入其他C ++ 17/C ++ 20兼容性問題，就可以努力改進它。總是歡迎反饋。如果您看到缺少或錯誤或不按預期行為的情況，只需打開問題，我會發表評論。
我通常需要文件系統功能，主要是fs::path ，但目錄訪問也是如此，當我開始使用C ++ 11時，我使用該語言更新來減少我的第三方依賴性。我可以放下大部分使用的東西，但仍然錯過了一些我開始實施的東西。最初，我將這些幫助者基於我自己的編碼和命名慣例。當C ++ 17最終確定時，我想使用該界面，但是花了一段時間才推動自己轉換我的課程。
該實施是基於C ++ 17標準的第30.10章，而接近該版本的草案是工作草案N4687。它來自C ++ 17的標準化之後，但與工作草案N4659相比，它包含最新的文件系統接口變化。使用v1.4.0凝視，使用C ++ 20編譯時，它會根據路徑排序順序和std::u8string處理N4860的操作來適應更改。
我要感謝致力於改進C ++的人們，我真的很喜歡語言如何以C ++ 11和以下標準演變。保持良好的工作！
如果您問自己， ghc代表是什麼，那隻是gulraks helper classes ，是的，我知道，不是很有想像力，但是我想要一個短名稱空間，並且在我的某些私人課程中使用了它（所以它與Haskell無關，對不起，對Clash的名字clash）。
ghc::filesystem是在MACOS上開發的，但是在MACOS，Windows，各種Linux發行版，FreeBSD和Solaris上的v1.5.12上測試了CI。它應該使用C ++ 11強的編譯器對其中的任何一個工作。另外，還有一些檢查可以更好地在Android上工作，但是由於我目前沒有使用Android NDK測試，因此我不稱其為受支持的平台，對於與Emscripten一起使用它也是有效的。現在它是檢測到的平台的一部分，我解決了明顯的問題並進行了一些測試，因此應該沒問題。總而言之，我看不到它替換完整的C ++ 17或C ++ 20的std::filesystem ，它不會嘗試成為“更好的” std::filesystem ，如果您不能使用它，則幾乎可以下車（除UTF-8偏好外）。
重要的是：該實現遵循“無處不在的UTF-8”哲學，因為所有std::string實例都將被解釋與std::u8string編碼Wise和在UTF-8中相同。 std::u16string將被視為UTF-16。有關更多信息，請參見API的差異。
目前運行的單位測試：
標題配備了一組單位測試，並將CMAKE用作構建工具，而Catch2作為測試框架。所有測試均在CMAKE中註冊，因此CTEST突擊隊可用於運行測試。
所有針對此實施的測試都應成功，具體取決於您的環境，可能會有一些警告，例如，如果您沒有在Windows上創建符號鏈接或至少是測試的權利，那麼這些都只是有益的。
從MACOS或Linux下的項目目錄內部構建測試：
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make
ctest這會生成運行測試的測試二進製文件，最後一個命令執行它們。
如果默認編譯器是GCC 8或更新或更新的較新的編譯器，則它還嘗試構建針對GCC/Clangs std::filesystem實現的測試二進制編譯版本，稱為std_filesystem_test ，作為額外的測試。理想情況下，所有測試都應通過所有文件系統實現進行編譯並取得成功，但實際上，行為存在一些差異，有時由於標準中的解釋空間，並且這些實現也可能存在問題。
最新版本的版本是v1.5.14，可以在此處找到源檔案。
最新的本地前後版本是v1.4.0，可以在此處找到源檔案。
最新的Pre-C ++ 20支持版本是v1.3.10，可以在此處找到源檔案。
當前，只有最新的次要版本版本會收到錯誤綴），因此，如果可能的話，您應該使用最新版本。
由於ghc::filesystem首先是僅標頭庫，因此將標題或include/ghc目錄複製到您的項目文件夾中或指向您的inceply inclage to to filesystem.hpp hepp hepter（或ghc/filesystem.hpp ）應該足以將其複製到您的項目文件夾中。
一切都在命名空間ghc::filesystem中，因此僅作為後備可能是：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs = std::filesystem;
# else
# include " filesystem.hpp "
namespace fs = ghc::filesystem;
# endif如果您還要使用帶有path支持作為後備的fstream包裝器，則可以使用：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " filesystem.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endif現在您有EG fs::ofstream out(somePath);它是包裝紙或C ++ 17 std::ofstream 。
請注意，作為僅限標題庫，它並沒有隱藏它使用系統的事實，因此它們“污染”了您的全局名稱空間。使用基於轉發/實現頭的方法（請參見下文）避免這種情況。對於Windows，它需要Windows.h ，在包含filesystem.hpp或fs_std.hpp標頭之前，定義WIN32_LEAN_AND_MEAN或NOMINMAX可能是一個好主意，以減少您的全局名稱空間的污染和編譯時間。它們不是由ghc::filesystem定義的，以與需要完整Windows.h上下文組合。
提示：還有一個名為ghc/fs_std.hpp的標題，它實現了文件系統實現的動態選擇，當您想要std::filesystem時，您可以將其包含在內，而不是ghc::filesystem ghc/filesystem.hpp 。
另外，從v1.1.0 ghc::filesystem開始也可以通過包括其他兩個包裝器標頭之一來使用。這些允許在大多數位置（ ghc/fs_fwd.hpp ）中包含轉發版本，而將實現詳細信息隱藏在單個CPP文件中，其中包括ghc/fs_impl.hpp來實現所需的代碼。使用ghc::filesystem以這種方式確保系統包含僅在CPP文件中可見，所有其他位置均乾淨。
請注意，當前不支持將實現隱藏到Windows-dll中，因為接口中具有C ++標準模板的DLL接口是不同的野獸。如果有人願意嘗試一下，我可能會整合一個PR，但目前正在研究自己並不是當務之急。
如果使用轉發/實現方法，您仍然可以使用這樣的動態切換：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifdef GHC_USE_STD_FS
# include < filesystem >
namespace fs {
using namespace std ::filesystem ;
using ifstream = std::ifstream;
using ofstream = std::ofstream;
using fstream = std::fstream;
}
# else
# include " fs_fwd.hpp "
namespace fs {
using namespace ghc ::filesystem ;
using ifstream = ghc::filesystem::ifstream;
using ofstream = ghc::filesystem::ofstream;
using fstream = ghc::filesystem::fstream;
}
# endif在實施中隱藏CPP中，您可以使用（在任何包含ghc/fs_fwd.hpp的包含之前，都要優先：
# if _MSVC_LANG >= 201703L || __cplusplus >= 201703L && defined(__has_include)
// ^ Supports MSVC prior to 15.7 without setting /Zc:__cplusplus to fix __cplusplus
// _MSVC_LANG works regardless. But without the switch, the compiler always reported 199711L: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
# if __has_include(<filesystem>) // Two stage __has_include needed for MSVC 2015 and per https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
# define GHC_USE_STD_FS
// Old Apple OSs don't support std::filesystem, though the header is available at compile
// time. In particular, std::filesystem is unavailable before macOS 10.15, iOS/tvOS 13.0,
// and watchOS 6.0.
# ifdef __APPLE__
# include < Availability.h >
// Note: This intentionally uses std::filesystem on any new Apple OS, like visionOS
// released after std::filesystem, where std::filesystem is always available.
// (All other __<platform>_VERSION_MIN_REQUIREDs will be undefined and thus 0.)
# if __MAC_OS_X_VERSION_MIN_REQUIRED && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
|| __IPHONE_OS_VERSION_MIN_REQUIRED && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
|| __TV_OS_VERSION_MIN_REQUIRED && __TV_OS_VERSION_MIN_REQUIRED < 130000
|| __WATCH_OS_VERSION_MAX_ALLOWED && __WATCH_OS_VERSION_MAX_ALLOWED < 60000
# undef GHC_USE_STD_FS
# endif
# endif
# endif
# endif
# ifndef GHC_USE_STD_FS
# include " fs_impl.hpp "
# endif提示：還有其他輔助助手標頭，名為ghc/fs_std_fwd.hpp和ghc/fs_std_impl.hpp使用此技術，因此，如果您想動態選擇Filesystem實現，則只需包含它們即可。
Starting from v1.1.0, it is possible to add ghc::filesystem as a git submodule, add the directory to your CMakeLists.txt with add_subdirectory() and then simply use target_link_libraries(your-target ghc_filesystem) to ensure correct include path that allow #include <ghc/filesystem.hpp> to work.
CMakeLists.txt提供了一些定制其行為的選項：
GHC_FILESYSTEM_BUILD_TESTING編譯測試，用作subsodule時默認OFF不在else ON 。GHC_FILESYSTEM_BUILD_EXAMPLES編譯示例，將默認OFF當作subsodule時，否則ON 。GHC_FILESYSTEM_WITH_INSTALL添加安裝目標以構建，當用作subsodule時，默認值是OFF ON 。GHC_FILESYSTEM_BUILD_STD_TESTING編譯std_filesystem_test ，與std::filesystem運行的測試套件的變體，默認為GHC_FILESYSTEM_BUILD_TESTING 。只有將編譯器檢測到能夠做到這一點時才完成。GHC_FILESYSTEM_TEST_COMPILE_FEATURES可以將cxx_std_20設置為覆蓋CMAKE_CXX_COMPILE_FEATURES filesystem_test_cpp20功能列表。請使用Hedronvision/Bazel-CC-Filesystem-Backport，它將自動為您設置所有內容。
如果將來的更改可能會使版本對此進行反應，則有一個版本的宏GHC_FILESYSTEM_VERSION定義了定義的版本，但我不打算破壞任何內容。它是十進制數字的版本(major * 10000 + minor * 100 + patch) 。
注意：僅在發布下一個版本時，僅將修補版本用於發行版，並且僅在提交之間使用奇數補丁版本。
除了下一節中所述的一些差異之外，此版本中幾乎沒有任何文檔，因為任何std::filesystem文檔都可以起作用。因此，您可以轉到https://en.cppreference.com/w/cpp/filesystem，以描述此庫的組件。
當使用C ++ 11，C ++ 14或C ++ 17編譯時，API在可能的情況下遵循C ++ 17標準，除了std::string_view參數僅在C ++ 17上支持。使用C ++ 20編譯時， ghc::filesysytem默認為C ++ 20 API，帶有char8_t和std::u8string接口以及不推薦使用的fs::u8path Factory方法。
注意：如果應在C ++ 20模式下執行C ++ 17 API，請使用Define GHC_FILESYSTEM_ENFORCE_CPP17_API 。 Even then it is possible to create fws::path from std::u8string but fs::path::u8string() and fs::path::generic_u8string() return normal UTF-8 encoded std::string instances, so code written for C++17 could still work with ghc::filesystem when compiled with C++20.
此處記錄了標準的唯一補充：
ghc::filesystem::ifstream ， ghc::filesystem::ofstream ， ghc::filesystem::fstream這些是圍繞std::ifstream ， std::ofstream和std::fstream簡單包裝器。他們只需添加一個open()方法和一個帶有ghc::filesystem::path參數的構造函數，因為C ++ 17中的fstream變體具有它們。
ghc::filesystem::u8arguments這是一個輔助類，當前在非Windows平台上檢查UTF-8編碼
::CommandLineToArgvW (::GetCommandLineW(), &argc)然後將它們轉換為UTF-8，然後替換argc和argv 。這是一個類似警衛的課程，在超出範圍時會恢復其變化。
因此，基本用法是：
namespace fs = ghc::filesystem;
int main ( int argc, char * argv[])
{
fs::u8arguments u8guard (argc, argv);
if (!u8guard. valid ()) {
std::cerr << " Bad encoding, needs UTF-8. " << std::endl;
exit (EXIT_FAILURE);
}
// now use argc/argv as usual, they have utf-8 encoding on windows
// ...
return 0 ;
}這樣，只要main的範圍有效，就可以對argv進行UTF-8編碼。
注意：在MacOS上，在XCode下進行調試時，當前代碼將返回false ，因為XCode以US-ASCII啟動應用程序作為編碼，無論實際使用什麼編碼，甚至在產品方案中設置LC_ALL都不會更改任何編碼。我仍然需要調查。
由於此實現基於我的私人助手類中的現有代碼，因此它得出了其一些限制。從v1.5.0開始，該差異與標準C ++ 17/C ++ 20 API之間的大部分差異。
該實現具有LWG缺陷＃2682，＃2935，＃2936和＃2937的可切換行為。 The currently selected behavior (starting from v1.4.0) is following #2682, #2936, #2937 but not following #2935, as I feel it is a bug to report no error on a create_directory() or create_directories() where a regular file of the same name prohibits the creation of a directory and forces the user of those functions to double-check via fs::is_directory if it really worked.較新的紙張WG21 P1164R0也提倡將目錄創建以該名稱為錯誤的文件創建更直觀的方法，在KONA 2019會議上同意了修訂P1161R1，請參閱Merge and GCC，現在已轉換為遵循其提案（GCC＃86910）。
// methods in ghc::filesystem::path:
path& operator +=(basic_string_view<value_type> x);
int compare (basic_string_view<value_type> s) const ;這些並未在C ++ 11和C ++ 14下實現，因為沒有std::basic_string_view可用，我確實想保持此實現自動化，並且不為C ++ 11/14編寫完整的C ++ 17升級。從v1.1.0開始，當C ++ 20的C ++ 17下編譯ghc::filesystem時，這些都得到了支持。
從v1.5.2 ghc::filesystem開始，將嘗試使用std::experimental::basic_string_view在其中檢測到可用性。此外，如果您具有basic_string_view兼容C ++ 11實現GHC_HAS_CUSTOM_STRING_VIEW std::basic_string_view實現導入ghc::filesystem namespace with：
namespace ghc {
namespace filesystem {
using my::basic_string_view;
}
}在包含文件系統標頭之前。
為了不依賴任何外部第三方庫，並且仍然保持便攜式和緊湊，此實現遵循“ utf-8無處不在”理念，因為所有std::string實例都將被解釋與std::u8string編碼明智和在UTF-8中相同。 std::u16string將被視為UTF-16和std::u32string將被視為Unicode Codepoint。根據std::wstring字符的大小，它將將std::wstring處理為UTF-16（例如Windows）或char32_t UNICODE CODEPORTS（當前所有其他平台）。
從v1.5.0 ghc::filesystem開始，遵循C ++ 17標準，即使用wchar_t和std::wstring作為內部用於路徑表示的類型。通過定義GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE和get filesystem::path::string_type as std::string and filesystem::path::value_type as wchar_t as wchar_t 。
如果您需要使用v1.5.0及以上的一些Windows API調用Windows API，只需使用Windows-API調用的W-Variant（例如GetFileAttributesW(p.c_str()) ）。
注意：通過定義GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE使用舊行為時，請使用path::wstring()成員（例如GetFileAttributesW(p.wstring().c_str()) ）。這為您提供了獨立於UNICODE宏的Unicode變體，並使Windows，Linux和MacOS之間的共享代碼更加容易，並且可以與std::filesystem和ghc::filesystem一起使用。
std::string path::u8string () const ;
std::string path::generic_u8string () const ;
vs.
std::u8string path::u8string () const ;
std::u8string path::generic_u8string () const ;這兩種方法的返回類型取決於使用的C ++標準，如果定義了GHC_FILESYSTEM_ENFORCE_CPP17_API 。在C ++ 11，C ++ 14和C ++ 17上，或定義GHC_FILESYSTEM_ENFORCE_CPP17_API時，返回類型為std::string ，並且在沒有定義的C ++ 20上，它是std::u8string 。
我創建了一個Wiki條目，內容涉及可能導致此處提及的不同std::filesystem實現之間的許多行為差異，但是此讀數只試圖解決ghc::filesystem與這些設計之間的設計選擇差異。我嘗試不時更新Wiki頁面。
歡迎任何其他觀察結果！
由於v1.5.0，該實現的完整內部力學fs::path在其中更改為本機格式為內部表示。創建Windows下方的任何混合斜線fs::path對象（例如，使用"C:foo/bar" ）通過generic_string() API通過native()和"C:/foo/bar"帶領"C:foobar"帶領乾淨路徑。在所有平台上，即使標準和其他實現都不執行此操作，刪除了冗餘的其他分離器。
此外，此實現遵循標準建議，以處理Windows上"//host/path"和USC路徑的POSIX路徑，也具有root-name（例如"//host" ）。 GCC實施在Ubuntu 18.04上測試時沒有選擇這樣做，而MACOS則使用GCC 8.1.0或Clang 7.0.0進行測試。此差異將顯示為std::filesystem下的警告。這導致了operator/=(path& p) ，其中任何帶有p.is_absolute()的路徑p都會降低為作業，而此實現的例外是*this == *this.root_name()和p == preferred_separator將完成正常的附錄，以便允許。
fs::path p1 = " //host/foo/bar/file.txt " ;
fs::path p2;
for ( auto p : p1) p2 /= p;
ASSERT (p1 == p2);對於所有非宿主領導路徑，該行為將與標準描述的行為匹配。
作為Windows上的符號鏈接，由於Windows Vista（具有嚴格的安全性限制）或多或少受到支持，並且由於Windows 10的一些較早構建（當激活“開發人員模式”被激活時）很少使用（2018年），但很少使用，但仍受到此實施的支持。
Windows ACL權限功能很糟糕地轉化為C ++ 17文件系統接口中使用的POSIX權限位蒙版。因此，當前在user級別合成file_status中返回的權限，並將其複製到group和other級別。仍然有一些與Windows許可系統進行更多互動的潛力，但是當前使用此實現的設置或閱讀權限肯定不會導致預期的行為。
extension()確實返回了目錄名稱".."的非空結果。ghcFilesystem::ghc_filesystem現在無條件地設置stem()上， filename()和fs::path的extension() ，如果結腸在文件名中，將返回錯誤的結果fs::last_write_time(path, time, ec) iOS，TVOS和WatchOS上的設置器fs::directory_entry::refresh()現在，始終如一status()不會將符號鏈接到不存在的目標上，但是使該條目具有file_type::not_found作為類型EINTR ，以避免網絡文件系統上的錯誤fs::copy_file()現在還復制了權限fs::copy_file()忽略skip_existing選項。dirent::d_type並修復構建配置和測試以支持Solaris作為新平台的系統上刪除了GHC_NO_DIRENT_D_TYPE的需求。PATH_MAX ，則將定義一個。fs::remove_all現在只是刪除符號鏈接而不是關注它們。fs::space ，其中可能會在乘法中發生數值溢出。fs::create_directories不再在長文件名上打破。ghc::filesystem處理的已安裝文件夾/卷作為符號鏈接，導致fs::canonical在包含這些的路徑上失敗。recursive_directory_iterator將不會嘗試輸入DEAD SYMLINKS。fs::remove失敗，另請參見（Microsoft/STL＃1511）有關Windows上的std::fs中的相應問題。GHC_NO_DIRENT_D_TYPE允許操作系統檢測能夠支持系統，而無需dirent.d_type成員，實驗性的第一個QNX編譯支持作為初始用例，固定問題的固定問題返回dt_unknown的文件系統（例如，reiserfs）。string_view支持。<ghc/fs_std.hpp>或<Availability.h> ghc/fs_std_fwd.hpp>/ <ghc/fs_std_fwd.hpp>或<ghc/fs_std.hpp>或<ghc/fs_std_impl.hpp> 。std::filesystem功能得到支持，因此使用標準章節號碼是誤導的，並由在版本上（大部分）保持一致的標籤式章節名稱所取代。recursive_directory_iterator的性能，在libc ++和libstdc ++之間的大樹上的遞歸迭代。ghc::filesystem的增強功能現在對Cygwin具有初步支持。進行更改以允許測試成功地進行編譯和運行（使用GCC 10.2.0測試），反饋和其他PRS歡迎，因為它目前不屬於CI配置。GHC_FILESYSTEM_BUILD_STD_TESTING以覆蓋std::filesystem測試的其他構建，以進行比較，並且有可能使用GHC_FILESYSTEM_TEST_COMPILE_FEATURES預填充使用comake_cxxx_coxx_cox__cypilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilespilesepilespilespile_feater CMAKE_CXX_COMPILE_FEATURESdirectory_entry Creation在用recursive_directory_iterator在較大的目錄樹上的測試中導致約20％-25％。wchar_t不在非Windows後端的支持char類型列表中。string_view支持可用於<string_view>或<experimental/string_view>在可用時使用，並在定義GHC_HAS_CUSTOM_STRING_VIEW時允許使用自定義basic_string_view實現實現，並將String View導入到ghc::filesystem namespace之前。std::filesystem測試現在與-lrt鏈接以避免問題。fs::hard_link_count的測試用例由於文件系統行為而失敗，測試案例已被調整為考慮到這一點。GHC_FS_API和GHC_FS_API_CLASS現在在設置外部時被尊重以允許行為覆蓋。make install文件。GHC_FILESYSTEM_BUILD_TESTING ， GHC_FILESYSTEM_BUILD_EXAMPLES和GHC_FILESYSTEM_WITH_INSTALL實現的情況，禁止在使用此this add_subdirectory時，可以將其設置為“ facter” fix，允許將它們設置為facte fix fix fix，允許將它們設置為它們。fs::path的Windows版本最初是由基於POSIX的實現創建的。這導致窗戶上的fs::path內部的可變緩存，即使對於const方法，這本質上也不是線程安全。為了不在次優的解決方案中添加其他補丁，這次我將path代碼重新設計為現在存儲本機路徑代表。這更改了很多代碼，但是當與wchar_t結合使用時，作為value_type ，有助於避免了對Win-API的通話進行大量轉換。fs::path::native()和fs::path::c_str()現在可以noexcept標準任務wchar_t是fs::path::value_type和std::wstring的默認值是fs::path::string_type的默認值。fs::path的const方法上的線程安全不再是問題GHC_WIN_DISABLE_AUTO_PREFIXES來禁用Windows上長路徑的自動前綴，對於所有其他類型的前綴或名稱空間，該行為遵循MSVC std::filesystem::path的行為。char / std::string的方法，則可以使用GHC_WIN_DISABLE_WSTRING_STORAGE_TYPE激活它fs::file_status的增強功能現在支持operator== std::filesystem中帶有C ++ 20。fs::path::parent_path()有一個性能問題，因為它仍在使用基於循環的方法從元素中重新創建父級。這造成了許多臨時性，尤其是在漫長的道路上太慢。char8_t和std::u8string在Source為參數類型的情況下支持U8Stringfs::path::u8string()和fs::path::generic_u8string()現在返回std::u8stringfs::path支持太空飛船操作員<=>GHC_FILESYSTEM_ENFORCE_CPP17_API ghc::filesystem將落回舊的fs::path::u8string()和fs::path::generic_u8string() api（如果首選）fs::proximate(p, ec)的BugFix，其中內部呼叫fs::current_path()不使用error_code變體，而是拋出可能的異常而不是設置ec 。LWG_2936_BEHAVIOUR現在正在打開。Source參數的問題。constexpr文件系統位掩碼的位操作。__MAC_OS_X_VERSION_MIN_REQUIRED ，以確保僅在部署目標至少在catalina時才在MacOS上選擇std::filesystem 。directory_iterator和recursive_directory_iterator的BugFix與skip_permission_denied選項有一個問題，這導致無法跳過MacOS上的SIP Protected文件夾。_MSVC_LANG的增強功能，除了__cplusplus ，在幫助標頭中，即使在/Zc:__cplusplus不使用時，也可以在__cplusplus中使用。fs::exists false或fs::status上的false或未找到的eRrors。名稱空間路徑不再過濾。filesystem_test.cpp中的TestAllocator已完成，以滿足使用devtoolset-9在CentOS 7上構建的要求。 Centos 7和Centos 8現在已成為CI構建的一部分。LWG_2936_BEHAVIOUR ，該開關允許啟用C ++ 17 fs::path::compare行為，其中比較就像是元素明智的路徑比較，如LWG 2936和C ++ 20 [fs.path.compare] 。它在v1.3.6中為默認值，並且將從v1.4.0開始，因為它會更改排序。std::fstream的wchar_t版本，如果將gcc與libc ++一起使用，則在Windows上使用Windows上的ghc::filesystem::fstream包裝器。fs::directory_options::skip_permission_denied和使用Emscripten編譯的初步支持時，更好地處理目錄迭代器的權限問題。ghc::filesystem現在支持在殘疾人異常的項目中使用。在此模式下，使用錯誤處理異常的API簽名，感謝PR（此解決＃60和＃43）ERROR_FILE_TOO_LARGE常數而發生錯誤。fs::lexically_relative的bugfix並沒有忽略基本參數的落後斜線，感謝PR＃57。fs::create_directories for n of Inde Indie true返回的bugfix，因為目錄已經存在。error_code 。fs::path時錯誤處理領先空格的錯誤處理。timespec字段，以避免警告。ghc::filesystem從BSD-3-C-CRAUSE重新許可到MIT許可證。 （請參閱＃47）fs::rename的BugFix並未根據標準要求替換現有的常規文件，而是錯誤的。該問題中提供的新測試和修復程序已實施。fs_fwd.hpp或fs_std_fwd.hpp進行轉發使用，在轉發部分中使用DWORD ，導致windows.h如果未在標頭之前包含Windows.h 。在這種情況下，更改了測試以給出錯誤，並刪除了DWORD的使用情況。GetProcAddress的返回值對MSYS2和MINGW GCC 9構建的-Wcast-function-type發出了警告。CMakeLists.txt將自動排除建築物示例和測試在用作subpoule時，配置選項現在使用前綴的名稱來減少衝突的風險。${CMAKE_INSTALL_LIBDIR}/cmake/ghcFilesystem的ghcFilesystemConfig.cmake /cmake_install_libdir}/cmake/ghcfilesystem for是find_package ，將目標導出為ghcFilesystem::ghc_filesystem 。error: redundant redeclaration of 'constexpr' static data member 。fs::create_directories上修復了TOCTOU情況，感謝PR！GHC_FILESYSTEM_WITH_INSTALL ，如果ghc::filesystem通過add_subdirectory使用，則默認為OFF。fs::path::lexically_normal()的問題，該問題在結果路徑以最終元素結尾時留下了尾隨的分離器..BUILD_TESTING和build_examples在cmake中禁用測試和BUILD_EXAMPLES ，為NO ， OFF或FALSE 。std::string_view中丟失專業化。std::string_view時，其他測試用例。fs::path::preferred_separator聲明沒有在PRE C ++ 17編譯器上編譯，也沒有訪問該測試，以顯示問題。將其修復到構造C ++ 11編譯器應接受並添加了在所有測試的所有組合中都成功的測試。fs::copy_options在其中一種情況下未從fs::copy到fs::copy_file轉發。strerror_r簽名。複雜的預處理器定義混合物通過超載統一的包裝器超載而被刪除以進行通常的調度。ghc::filesystem錯過的遠程/inmand方法a <vector>包括在Windows案例中。wchar_t/std::wstring接口的可選支持時，使用定義的GHC_WIN_WSTRING_STRING_TYPE在Windows上編譯Windows時，使用ghc/fs_std*.hpp標頭時，這是默認的，以增強兼容性。GHC_RAISE_UNICODE_ERRORS上的Unicode錯誤的可選文件系統異常/錯誤（而不是用更換字符U+FFFD替換無效的代碼點或UTF-8編碼錯誤）。fs::copy_file中的文件句柄洩漏。readdir/readdir_r中的錯誤fs::directory_iterator ;由於readdir_r現在已棄用，我決定將其放下，並且由此產生的代碼更加容易，更短，並且由於重構的速度更快std::filesystem崩潰的單元測試的修復程序fs::path::lexically_normal()的bugfix在".." - 序列中存在一些問題。fs::recursive_directory_iterator可能會遇到無盡的循環，方法depth（）和pop（）有問題，並且副本行為和input_iterator_tag符合符合度已損壞，添加了測試，std::filesystem構建測試和示例的支持，以進行互操作檢查。fs::weakly_canonical()測試std::fs的噪聲降低du示例，顯示用於在目錄樹中添加文件尺寸的recursive_directory_iterator 。fs::file_time_type測試幫助者中添加了錯誤檢查fs::copy()現在符合LWG＃2682，不稱呼“ copy_option :: create_symlinks”的使用，以在目錄上使用hpp作為擴展名為C ++，並且它們移動到include/ghc/以便能夠包含<ghc/filesystem.hpp>因為前者包括名稱可能是通用和與其他文件衝突。ghc::filesystem現在可以用作subpodul，並與add_subdirectory添加，並將自身導出為ghc_filesystem目標。要使用它，僅需要target_link_libraries(your-target ghc_filesystem) ，並且將設置包含目錄，因此#include <ghc/filesystem.hpp>將是有效的指令。您仍然只能將標題文件添加到您的項目中，然後從那裡包含它。ghc::filesystem聲明（ fs_fwd.hpp ），並將實現包裝到單個CPP中（ fs_impl.hpp ）fs::path API的std::basic_string_view變體。ghc::filesystem::path::generic_string()丟失返回語句filesystem.h被重命名為filesystem.hpp ，以更好地反映它是C ++語言標題。ghc::filesystem::remove()和ghc::filesystem::remove_all()現在都可以刪除單個文件，如果路徑不存在，則兩個都不會引起錯誤。ghc::filesystem::remove()中進行比較。ghc::filesystem::directory_iterator的Windows版本）現在釋放資源end()時釋放資源。ghc::filesystem::copy()和ghc::filesystem::remove_all中缺少error_code傳播。ghc::filesystem::recursive_directory_iterator::difference_type中添加了缺少的std名稱空間。-Wall -Wextra -Werror和固定的結果進行建築測試。fs.op.permissions Test與所有測試的std::filesystem實現（GCC，Clang，MSVC ++）一起工作。ghc::filesystem::u8arguments作為argv轉換器，以幫助遵循Windows上的UTF-8路徑。只需將其與argc和argv實例化，它將獲取命令行的Unicode版本並將其轉換為UTF-8。破壞者恢復了變化。examples文件夾，並希望有一些有用的示例用法。使用ghc::filesystem和C ++ 17 std::filesystem在可用時測試（和構建）示例。std::filesystem進行測試以進行比較。fstream包括。timespec / timeval使用。chrono轉換問題，並在Clang 7.0.0上進行了示例。ghc::filesystem::canonical現在將空路視為不存在的空路並報告錯誤。由於此ghc::filesystem::weakly_canonical現在返回不存在參數路徑的相對路徑。 （＃1）ghc::filesystem::remove_all現在還計數目錄已刪除（＃2）recursive_directory_iterator測試不尊重等量域問題和不可限制的約束，從而導致std::filesystem測試失敗。noexcept標記的方法和函數可能會間接提出異常。std_filesystem_test 。這是第一個公開版本。它實現了C ++ 17 std::filesystem的全部範圍，而沒有其他C ++ 17依賴項。
