标签: std-filesystem

我似乎找不到可能传递到 的ec参数中的错误代码列表std::filesystem::copy。

cppreference.com 似乎表明错误代码是特定于操作系统的。
查看Microsoft 文档（因为我对 Windows 错误代码特别感兴趣，尽管我确信其他操作系统的资源对其他人会有帮助），它看起来几乎像是相同源文档的复制/粘贴，没有任何附加信息任何 Windows 特定的内容。

我的猜测是，错误代码将与此处列出的错误代码相同，但是没有关于哪些错误代码与文件系统相关的信息，或者更具体地说与函数相关的信息copy()（超出了有根据的猜测）。

有谁有关于可能返回的潜在错误代码的任何资源，或者，如果我必须以困难的方式执行此操作（并手动尝试并检查不同的错误情况），我如何知道我是否有详尽的列表？

我想用来std::filesystem查询提供给我的函数的磁盘文件夹路径。我想知道我是否有该文件夹的写入权限。但我想在不实际尝试写入文件夹的情况下执行此操作。

最后一个要求部分是因为

• a) 我不想更改文件夹上文件系统的上次写入时间
• b）如果可能的话，我想学习如何仅通过以某种独立于平台的方式查询文件系统来做到这一点

看来这std::filesystem::status()就是我想要的功能。然而，该函数返回的权限标志包括owner_write、group_write和others_write。

我如何知道其中哪一个适用于我？我不知道我的应用程序/用户是所有者、组还是“其他”。can_i_write_to_this_folder()某处是否有某种功能正在运行？

我能找到的唯一与此相关的线程没有涉及的答案<filesystem>

[编辑] 人们似乎认为我正在寻找一些不切实际的可写性保证。我不是。我并不认为任何文件系统功能都是万无一失的。我不会将某些关键任务系统建立在这个决定的基础上

当<filesystem>他们过来给我们所有的东西directory_iterator和其他好东西时，他们所宣传的目的是有用的。所以当我发现这是真的时，我评估了它们并使用了它们。就像我对std::atomic<>参数包和std::variant许多其他东西所做的那样。我想我们都同意，多年来添加了一些东西，但事实证明并不是那么好。

现在，该库宣传了此功能，filesystem::status()旨在告诉我们（除其他外）文件或文件夹的权限。我想知道这个“访问”信息是否有任何实际用途。

共识似乎是事实并非如此。

我的程序应该创建两个具有用户指定路径的文件。我需要知道路径是否通向同一位置，以便在开始更改文件系统之前以错误结束。

由于路径来自用户，因此它们应该是非规范且奇怪的。例如，它们可能是./dir1/subdir/file，并且符号链接dir2/subdir/../subdir/file在哪里并且还不存在。预期的结果仍然是，它们是等价的。dir2dir1subdirtrue

std::filesystem::equivalent仅适用于已存在的文件。有没有类似的功能，没有这个限制？

我有一个由std::filesystem::path. 我想向此路径添加一些用户提供的文件名，并确保生成的路径不在根目录之外。

例如：

    std::filesystem::path root = "/foo/bar";
    std::filesystem::path userFile = "ham/spam";
    std::filesystem::path finalPath = root / userFile;

最后的路径没问题，就在里面/foo/bar。但是如果我给../ham/spam这个userFile变量，这将导致一个文件在 define 之外rootPath。

如何检查生成的文件是否保持在其允许的边界内？

我的问题如下：为了确定 Windows 平台上的两个路径是否相同，比较路径时不区分大小写，ei。“C:\test.txt”和“C:\Test.txt”解析为相同的文件元素。我可以通过使用std::filesystem::equal示例轻松解决这个问题，但对于这个特定问题，我想在操作系统往返上节省一点（在空闲状态下运行并在每个循环上进行 100 多次比较 - 我担心它会很明显）

using path = std::filesystem::path;
const bool result =  (path("C:\\test.txt").lexically_normal().make_preferred().native() == path("C:\\Test.txt").lexically_normal().make_preferred().native());

在比较时std::filesystem::path，即使通过调用进行词法规范化lexical_normal也是以通用方式完成的，因此也会考虑这种情况。这当然是有道理的，但除了我自己进行字符串比较之外，我看不到一种方法可以在不进行比较的情况下使用库来执行此操作：是否有可能以某种方式覆盖路径的比较方式？

我也调查过boost::filesystem，但据我所知也没有解决这个问题。

我有一个目录的路径，我想使用 C++ 的std::filesystem. 例如，如果路径是：

std::filesystem::path fake_path("C:\\fake\\path\\to\\my_directory\\");

我想得到“my_directory”。

我已经看到了这个答案，最初认为在 中起作用的内容在boost::filesystem中不起作用std::filesystem，尽管这可能不正确。无论哪种方式，我都不相信这是重复的，因为那个人专门询问boost::filesystem并以文件结尾的路径。

我可以想到其他几种解决方案，例如获取fake_path.end() - 2或获取字符串并在分隔符上拆分，但没有一个像fake_path.filename()以前那样简单。

有没有一种干净的方法来获取目录路径的最后一部分，大致相当于调用.filename()文件的路径？

我在它刚刚出现时就开始使用experimental::filesystem，并且建议我以任何一种方式链接到“我的程序构建”中的“stdc++fs使用”，但是如果我省略了额外的链接命令，我可能会破坏某些东西/做一些不必要的事情吗？target_link_libraries(MyTarget stdc++fs)CMake.

这个问题是三年前提出的，似乎假设链接stdc++fs是必要的。

编辑：编译器版本是g++-9 (Homebrew GCC 9.3.0_1) 9.3.0，CMake版本是3.16。

非常感谢！

以下程序崩溃：

#include <iostream>
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
    fs::path p1 = "/usr/lib/sendmail.cf";
 
    std::cout << "p1 = " << p1 << '\n';
}

汇编：

$ g++ -std=c++17 pathExistsTest.cpp
$ ./a.out 
p1 = "/usr/lib/sendmail.cf"
[1]    35688 segmentation fault (core dumped)  ./a.out

在 Ubuntu 20.04 上测试，编译器为 GCC 8.4.0。

Valgrind，这是切割输出：

==30078==    by 0x4AE5034: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==30078==    by 0x4A312B5: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==30078==  Address 0x2b is not stack'd, malloc'd or (recently) free'd
==30078== 
==30078== 
==30078== Process terminating with default action …

我正在编写一个 linux 命令行程序，它将返回目录的大小。该程序按预期工作，除非专门处理根目录。我知道根目录中的许多文件没有大小，因为它们是用于表示系统信息（如 /proc/）或 /dev/null/ 之类的特殊文件，所以我std::filesystem::directory_options::skip_permission_denied在 for 循环中使用以跳过权限问题，我使用多个 try/catch 块来捕获异常。

但是，即使这样，仍然会抛出权限被拒绝的异常。请参阅以下代码：

byte_size_and_num_files find_recursive(const std::filesystem::path& path)
{
    byte_size_and_num_files bsnf;
    std::filesystem::path pa;
    try
    {
      for(const auto& p: std::filesystem::recursive_directory_iterator(path, std::filesystem::directory_options::skip_permission_denied))
      {
          pa = p.path();
          if (std::filesystem::exists(p) && !std::filesystem::is_directory(p))
          {
            try
            {
              if(std::filesystem::is_regular_file(pa))
              {
                bsnf.size += std::filesystem::file_size(p);
                bsnf.files++;
              }
              else
                std::cout << "SKIPPED: size is not determinable: " << pa << "\n";
            }
            catch(std::filesystem::filesystem_error& e)
            {
              std::cout << "SKIPPED: size is not determinable: " << pa << "\n";
            }
            catch(std::bad_alloc)
            {
              std::cout …

为什么报告is_regular_file中的那个函数std::filesystem对于符号链接来说是正确的？我查看了该调用的文档，但找不到原因，并且 cppreference 上的示例表现出相同的行为。

举个例子，如果我们看一下二进制文件pidof；它作为符号链接存在/usr/sbin/pidof并正确标记为符号链接，如下所示stat：

[@rhel9 ~]$ stat /usr/sbin/pidof 
  File: /usr/sbin/pidof -> /usr/bin/pidof
  Size: 14          Blocks: 0          IO Block: 4096   symbolic link
Device: fd00h/64768d    Inode: 34952482    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:bin_t:s0
Access: 2024-02-05 15:46:24.124158991 +0000
Modify: 2023-01-28 09:40:21.000000000 +0000
Change: 2023-05-09 17:34:59.432002380 +0100
 Birth: 2023-05-09 17:34:59.432002380 +0100

如果我们点击链接并运行stat它：

[@rhel9 ~]$ stat /usr/bin/pidof 
  File: /usr/bin/pidof
  Size: 23760       Blocks: 48         IO Block: …