我尝试在OS X 10.9.5上使用以下命令在外部驱动器上创建数十万张照片的MD5校验和。但是我得到了一堆错误。我使用以nul结尾的文件名为xargs的find，因为我认为它运行得最快。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当我在我的硬盘上运行原始命令时，我看到一堆“没有这样的文件或目录”错误，并且这些文件被跳过，没有得到校验和。
有什么想法吗
1条答案
按热度按时间zfycwa2u1#
我没有解决办法，但我有一个变通办法：不要使用Apple的HFS驱动程序（在Bootcamp中）将文件从HFS驱动器复制到NTFS，而是通过SMB或VMWare Fusion的共享文件夹（实际上是SMB？）
有两种方法来创建一个e-grave字符。一种是使用CP 1252中的扩展ASCII 0xE 8，另一种是使用Unicode字节0x 0065（常规字母'e'，ASCII 0x 65）+0x 0300（组合grave重音）。
当我在Bootcamp中复制文件时，文件名包含UTF-16 le字节序列0x 65 0x 00 0x 00 0x 03（常规字母'e' +组合严重口音）
当我通过VMWare的共享文件夹或通过文件共享在VMWare fusion中复制文件时，文件名包含UTF-16 le字节序列0xE 800（Windows代码页1252扩展ASCII电子坟墓字符）。
回到OS X下，将
find的输出通过管道传输到hexdump -C，对于这个字符的两种变体，给出了相同的UTF-8字节序列：65 cc 80。这大概就是为什么我在OSX下会崩溃的原因。