前言 我正在开发一个用 java 编写的依赖于平台的媒体数据库，其中媒体文件由文件哈希标识。用户应该能够移动文件，所以我不想依赖任何文件路径。导入后，我将路径和哈希值存储在我的数据库中。我开发了一种基于准确性和性能之间的权衡的快速文件哈希 ID 算法，但快速并不总是足够快。:)
为了更新和导入媒体文件，我需要（重新）创建库中所有文件的文件哈希。我现在的想法是只计算一次散列并将其存储在文件元数据（扩展属性）中，以提高支持扩展文件属性的文件系统的性能。(NTFS, HFS+, ext3...) 我已经实现了，你可以在这里找到当前的源：archimedesJ.io.metadata
尝试 乍一看，Java 1.7 通过UserDefinedFileAttributeView提供了一种处理元数据的好方法。对于大多数平台，这是有效的。遗憾的是，UserDefinedFileAttributeView在 HFS+ 上不起作用。尽管如此，我不明白为什么特别不支持 HFS+ 文件系统——它是元数据的主要格式之一？（请参阅相关问题-不提供任何解决方案）
如何使用 Java 在 OS X 上存储扩展文件属性？ 为了克服这个 java 限制，我决定使用OSX 上的xattr命令行工具，并将它与 Javas Process 处理一起使用来读取它的输出。我的实现有效，但速度很慢。（文件哈希的重新计算速度更快，多么讽刺！我正在 Mac BookPro Retina 上进行测试，带有 SSD。）
事实证明，xattr 工具的运行速度很慢。（写入速度很慢，但更重要的是读取属性也很慢）为了证明这不是 Java 问题而是工具本身，我创建了一个简单的 bash 脚本，以便在具有我的自定义属性的几个文件上使用 xattr 工具：
FILES=/Users/IsNull/Pictures/
for f in $FILES
do
xattr -p vidada.hash $f
done
如果我运行它，这些行会彼此“快速”显示，但我希望在几毫秒内立即向我显示输出。一点点延迟是清晰可见的，因此我猜这个工具并没有那么快。在 java 中使用它会给我一个额外的开销来创建一个进程，解析输出，这使得它甚至有点慢。
有没有更好的方法来使用 Java 访问 …