当目录包含 OS X 上具有特殊字符的文件时，添加“-type f”会导致“查找”错误答案

【问题标题】：Adding "-type f" is causing errors from "find" when a directory contains files with special characters on OS X当目录包含 OS X 上具有特殊字符的文件时，添加“-type f”会导致“查找”错误
【发布时间】：2015-03-14 10:40:10
【问题描述】：

我尝试在 OS X 10.9.5 上使用以下命令在外部驱动器上创建数十万张照片的 MD5 校验和。我得到了一堆错误。我正在使用 find 与通过管道传输到 xargs 的 nul 终止文件名，因为我认为它运行得最快。

find . -type f -not -name "checksums.md5" -print0 | xargs -0 md5 -r > checksums.md5

我已将其范围缩小到使用 -type f，您可以在以下示例中看到：

mymac:Finals user$ find . -name "0153*"
./0153_IMG_4812_Coniston village.jpg

mymac:Finals user$ find . -name "0153*" -type f
./0153_IMG_4812_Coniston village.jpg
find: ./0154_IMG_4814_Après hike.jpg: No such file or directory

mymac:Finals user$ find . -name "0154*"
./0154_IMG_4814_Après hike.jpg

mymac:Finals user$ find . -name "0154*" -type f
find: ./0154_IMG_4814_Après hike.jpg: No such file or directory

当我在硬盘驱动器上运行原始命令时，我看到一堆“没有这样的文件或目录”错误，并且这些文件被跳过，没有得到校验和。

有什么想法吗？

【问题讨论】：

当您使用名称模式“0153*”时，它真的抱怨以“0154”开头的文件吗？我认为它甚至不会检查类型，因为名称与模式不匹配。其他一些想法：外部驱动器使用什么文件系统？通过hexdump -C 将这些find 命令的输出和stderr 通过管道传输，并在两种情况下比较文件名的字节。还可以与同一目录上ls 的输出的十六进制转储进行比较。
是的，它确实在抱怨！！！！让我试试你的建议
在运行find之前尝试export LC_TYPE=C。
很难显示格式化的回复，但您正在处理文件系统的问题。这些文件位于 NTFS 驱动器上，但如果将文件复制到本地 (HFS)，则不会发生错误。无论文件是在 HFS 还是 NTFS 驱动器上，Hexdump 都显示相同的值“65 cc 80”。实际上我遇到了一些困难，因为 NTFS 驱动器上的“ls 0154*”也失败了，所以我不得不使用没有“-type f”的“find”
export LC_TYPE=C 没有帮助。

标签： macos bash shell find bootcamp

【解决方案1】：

我没有解决方案，但我有一个解决方法：不要使用 Apple 的 HFS 驱动程序（在 Bootcamp 中）将文件从 HFS 驱动器复制到 NTFS，而是通过 SMB 或 VMWare Fusion 的共享文件夹进行（实际上是 SMB？）

有两种方法可以创建电子坟墓角色。一种是使用 CP1252 的扩展 ASCII 0xE8，另一种我刚刚了解到的显然是使用 Unicode 字节 0x0065（正则字母 'e'，ASCII 0x65）+ 0x0300（结合重音）。

当我在 Bootcamp 中复制文件时，文件名包含 UTF-16le 字节序列 0x65 0x00 0x00 0x03（正则字母 'e' + 重音组合）

当我通过 VMWare 的共享文件夹或文件共享在 VMWare fusion 中复制文件时，文件名包含 UTF-16le 字节序列 0xE800（Windows 代码页 1252 扩展的 ASCII 电子坟墓字符）。

回到 OS X 下，将 find 的输出通过管道传送到 hexdump -C 会为该字符的两个变体提供相同的 UTF-8 字节序列：65 cc 80。这大概就是我在 OS X 下一切都崩溃的原因。

【讨论】：