Menambahkan -type f menyebabkan kesalahan find ketika direktori berisi file dengan karakter khusus di OS X

Saya mencoba membuat checksum MD5 dari ratusan ribu foto di drive eksternal menggunakan perintah berikut di OS X 10.9.5. Saya mendapatkan banyak kesalahan. Saya menggunakan find dengan nama file yang diakhiri nul yang disalurkan ke xargs karena menurut saya ini berjalan paling cepat.

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

Saya telah mempersempitnya menjadi penggunaan -type f, yang dapat Anda lihat pada contoh berikut:

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

Ketika saya menjalankan perintah asli di hard drive saya, saya melihat banyak kesalahan "Tidak ada file atau direktori", dan file-file itu dilewati, jangan di-checksum.

Ada ide?


macos bash shell find bootcamp
person Clam    schedule 15.01.2015    source sumber
comment
Apakah itu benar-benar mengeluh tentang file yang dimulai dengan 0154 ketika Anda menggunakan pola nama 0153*? Menurut saya, tidak perlu repot memeriksa jenisnya, karena namanya tidak cocok dengan polanya. Beberapa pemikiran lain: sistem file apa yang digunakan drive eksternal? Masukkan output dan stderr dari perintah find tersebut melalui hexdump -C dan bandingkan byte nama file dalam kedua kasus. Bandingkan juga dengan hex dump dari output ls pada direktori yang sama.   -  person Ken Thomases    schedule 16.01.2015
comment
Ya itu memang mengeluh!!!! Izinkan saya mencoba saran Anda   -  person Clam    schedule 16.01.2015
comment
Coba export LC_TYPE=C sebelum menjalankan find mungkin.   -  person Mark Setchell    schedule 16.01.2015
comment
Sulit untuk menampilkan balasan yang diformat, tetapi Anda sedang mengerjakan sesuatu dengan sistem file. File berada di drive NTFS, tetapi kesalahan tidak terjadi jika file disalin secara lokal (HFS). Hexdump menunjukkan nilai yang sama yaitu 65 cc 80 baik file tersebut ada di drive HFS atau NTFS. Sebenarnya saya mengalami kesulitan karena ls 0154* di drive NTFS juga gagal, jadi saya harus menggunakan find tanpa -type f   -  person Clam    schedule 16.01.2015
comment
export LC_TYPE=C tidak membantu.   -  person Clam    schedule 16.01.2015
comment
Coba gunakan saja ls pada direktori, tanpa pola glob. Jelas, Anda harus mencari hex dump. Atau Anda dapat memfilternya dengan grep sebelum menyalurkannya ke hexdump -C. Yaitu. ls | grep 0154 | hexdump -C.   -  person Ken Thomases    schedule 16.01.2015
comment
@Clam Mungkin Anda menimpa find entah bagaimana. Coba command find ...   -  person Reinstate Monica Please    schedule 16.01.2015
comment
@KenThomases: Anda benar tentang sistem file. Saya melihat folder di mesin Windows. File muncul dengan baik di Explorer, dan terbuka di Windows Photo Viewer. md5summer meskipun tidak bisa mengatasinya. Saya menyalin nama file dari Explorer ke notepad dan menemukan bahwa karakter Unicode digunakan untuk E-grave. Saya menggantinya dengan versi ASCII biasa (byte: 0xE8) dan ini menyelesaikan masalah untuk file di bawah OS X. Lucunya, hexdump -C menunjukkan urutan karakter UTF-8 yang sama untuk nama file yang rusak dan tetap: 65 cc 80.   -  person Clam    schedule 16.01.2015
comment
Apakah Anda mempertimbangkan untuk bertanya di situs Apple Stack Exchange, Ask Different?   -  person Jonathan Leffler    schedule 16.01.2015

Jawaban (1)


arrow_upward
0
arrow_downward

Saya tidak punya solusi, tapi saya punya solusi: jangan menyalin file dari drive HFS ke NTFS menggunakan driver HFS Apple (di Bootcamp), tetapi lakukan melalui folder bersama SMB atau VMWare Fusion (efektif SMB ?)

Ada dua cara untuk membuat karakter e-grave. Salah satunya adalah menggunakan ASCII 0xE8 yang diperluas dari CP1252, yang lain seperti yang baru saja saya pelajari tampaknya menggunakan byte Unicode 0x0065 (huruf biasa 'e', ​​ASCII 0x65) + 0x0300 (menggabungkan aksen kuburan).

Ketika saya menyalin file di Bootcamp, nama file berisi urutan byte UTF-16le 0x65 0x00 0x00 0x03 (huruf biasa 'e' + menggabungkan aksen kuburan)

Ketika saya menyalin file dalam fusi VMWare baik melalui folder bersama VMWare atau melalui berbagi file, nama file berisi urutan byte UTF-16le 0xE800 (karakter e-grave ASCII yang diperluas Halaman Kode Windows 1252).

Kembali ke OS X, menyalurkan keluaran find ke hexdump -C menghasilkan urutan byte UTF-8 yang sama untuk kedua varian karakter ini: 65 cc 80. Ini mungkin mengapa segalanya berantakan bagi saya di bawah OS X.

person Clam    schedule 16.01.2015