问题标签 [apfs]

在 WWDC 2016 上宣布的 APFS 的好处之一是能够非常快速地获取目录的大小，而不必遍历整个文件夹结构。给出的演示是 Finder 中的 Get Info 窗口，无需异步计算目录的大小。

我有一个 iOS 应用程序，我需要在其中显示目录的文件大小。现在我递归地做，总结所有子目录中所有文件的大小。但是现在 APFS 已经随 iOS 10.3 一起发布，我想利用新的文件系统更有效地完成它。某处有这个API吗？我没有在NSFileManager文档中看到它引用。现在我使用attributesOfItemAtPath和NSFileSize键。

我想缩小启动文件系统的大小（格式化为APFS），怎么做？

在 macOS Sierra 中，HFS+可以在不重启/重新挂载（in disk utility）的情况下进行缩小，但在 macOS High Sierra 中，这似乎是不可能的。

尽管在我使用 APFS 测试任何版本的 MacOS 时仍然是 beta（撰写本文时为 beta 4），但不会在 Monit Widget 中显示任何磁盘信息。摘要栏显示“磁盘 0%”，一旦选择，子内容就不会显示/甚至不会展开。Monit Widget 中的所有其他类别似乎都按预期工作。

其他人看到的一样吗？

通常使用以下命令创建 RAM 磁盘

返回例如 /dev/disk2 然后我会格式化磁盘，说

然后安装它：

此过程似乎不适用于 APFS。我在 High Sierra beta 9 上。 mount 命令没有输出任何错误，但路径没有挂载。

在我的情况下，hdid命令完成后，newfs_apfs -i /dev/disk2产生

然后当我输入时mount -t apfs /dev/disk2 /some/target/path，挂载命令似乎工作了 2 秒，没有给出任何输出，并且挂载不成功。

谁能告诉我如何真正制作一个 APFS RAM 磁盘它可以工作？:p

PS：我也尝试过类似diskutil partitionDisk /dev/disk2 GPT APFS myvolumename 0b的方法，它确实将卷安装到/Volumes/myvolumename但创建了另一个磁盘（disk3在这种情况下），这对我来说似乎很奇怪！

旧的 MoreFilesX 中有一个很棒的功能，即 FSExchangeObjectsCompat，它“在两个文件之间交换数据”。它通常用作安全保存方法的一部分，其中写出临时文件，然后调用 FSExchangeObjectsCompat 以将新保存的临时文件与旧的“原始”文件交换。它保留了所有元数据、权限等。

我在 APFS 卷上的 High Sierra 上看到此功能失败，而在 HFS+ 卷上从未失败。不足为奇——其中许多调用已被弃用。

但是做同样事情的 Cocoa NSFileManager 方法是什么？

macOS High Sierra 提供了一个新的文件系统：APFS。

该文件系统支持文件的克隆操作： 存储上没有数据重复。

cp命令有一个标志（-c），可以在终端（shell）中进行克隆。

但是之后我没有找到一种方法来识别这些克隆文件。

有人知道如何使用 shell 命令或现有命令中的标志来识别克隆文件，例如ls？

Apple 的新文件系统 APFS 带来了测试文件名相等性的新规则，它们与 HFS 不同。我正在寻找正确的方法来比较两个名称是否相等，特别是对于 APFS，但为了完整性，添加一个用于 HFS+ 检查也没有什么坏处。

为什么？因为我需要能够判断我在目录中找到的文件名是否与某个模式匹配，例如包含某个子字符串。为此，我需要匹配文件系统和 Finder 用于比较名称的确切规则。

对于这些文件系统的区分大小写的变体，这很容易，因为按字节比较就足够了，我相信（假设两个字符串都使用相同的编码）。

对于不区分大小写的 HFS+，我认为甚至还有一个特殊的比较选项，但我在 NSStringCompareOptions 中找不到这样的选项。我认为这是必要的，因为 HFS+ 使用的是旧版本的 Unicode 标准。我引用了 TN1150（很遗憾，它似乎不再在 Apple 网站上提供）：

Unicode 细微之处

HFS Plus 大量使用 Unicode 字符串来存储文件和文件夹名称。然而，Unicode 仍在不断发展，它在文件系统中的使用带来了许多挑战。本节描述了一些挑战，以及 HFS Plus 使用的解决方案。

重要提示：实现不得使用其本机平台实现的 Unicode 实用程序（用于分解和比较），除非这些算法等同于此处定义的 HFS Plus 算法，并且保证永远如此。这种情况很少见。平台算法倾向于随着 Unicode 标准而发展。HFS Plus 算法不能进化，因为这样的进化会使现有的 HFS Plus 卷失效。

啊，我想到了关于获得所用编码的 HFS+ 版本的部分：

注意：Mac OS 文本编码转换器提供了几个常量，可让您与存储在 HFS Plus 卷上的规范、分解形式相互转换。使用 CreateTextEncoding 创建文本编码时，应将 TextEncodingBase 设置为 kTextEncodingUnicodeV2_0，将 TextEncodingVariant 设置为 kUnicodeCanonicalDecompVariant，并将 TextEncodingFormat 设置为 kUnicode16BitFormat。使用这些值可确保 Unicode 与 HFS Plus 卷上的格式相同，即使随着 Unicode 标准的发展。

那么，正确比较 HFS+ 和 APFS 名称的现代方法是什么？

我一直遇到这个问题，我发现在网络上没有任何信息，并且希望得到一些帮助，因为过去几天我一直在努力解决这个问题，但没有任何线索。

为什么我的 java 应用程序突然停止为 APFS 工作？如果我将应用程序移动到非 APFS USB 上它可以工作，但是当我将应用程序移动到格式化为 APFS 的 SSD 时，它会停止工作。

当我检查应用程序日志时，事实证明，由于某种原因，某些库在从格式化为 APFS 的 SSD 运行时没有被应用程序正确导入/识别。为什么它在 APFS SSD 与 HFS+ USB/硬盘驱动器中的行为会有所不同？

我已经隔离了这个案例，发现只有APFS是共同因素。我已经在其他设备上测试过它，那些在没有 APFS 驱动器的情况下运行 High Sierra 的设备，以及那些使用尚未转换为 APFS 驱动器的 SSD 运行 Sierra 的设备，并且只有那些使用 APFS 文件系统格式的设备才会遇到问题。

附加信息：

• Java 应用程序已正确签名，它是个人分发的，但不是通过 App Store 分发的。
• 应用程序是使用 AppBundler 而不是 JavaPackager 捆绑的。
• 应用程序在以前版本的 OSX 上运行，并且已经在数百个 OSX 介于 10.8 - 10.12 之间的 Mac 设备上进行分发和测试
• 不知何故无法识别的库是 apache 库，例如 commons-lang-2.6（我们尚未升级到 3）、commons-logging（必须手动将日志输出到桌面以查看发生了什么）。奇怪的是，app 能够正确导入 sqlite 库。

感谢您的关注，并希望得到任何建议！

我听说APFS 中的时间戳以纳秒为单位。

是否有任何命令能够以纳秒为单位显示 APFS 时间戳？

我试过了ls，stat但到目前为止还没有运气。

我的团队为 Windows 和 Mac 开发了几种产品。到目前为止，我们使用 Vise-x 为 Mac 创建安装程序（并为 Windows 安装屏蔽），由于某种原因，在 APFS 上搜索（使用 Vise-x）挂起。由于这个原因，我们想用新的安装程序创建者替换 vise-x。

任何人都可以推荐一个好的、强大的安装程序创建器（完全支持）Mac（甚至更好的跨平台）吗？