การเพิ่ม -type f ทำให้เกิดข้อผิดพลาดจากการค้นหาเมื่อไดเร็กทอรีมีไฟล์ที่มีอักขระพิเศษบน OS X

ฉันกำลังพยายามสร้างการตรวจสอบ MD5 ของรูปภาพหลายแสนรูปบนไดรฟ์ภายนอกโดยใช้คำสั่งต่อไปนี้บน OS X 10.9.5 ฉันได้รับข้อผิดพลาดมากมาย ฉันใช้ find กับชื่อไฟล์ที่สิ้นสุดด้วย nul และไพพ์เป็น xargs เพราะฉันคิดว่ามันทำงานเร็วที่สุด

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

เมื่อฉันรันคำสั่งเดิมบนฮาร์ดไดรฟ์ ฉันเห็นข้อผิดพลาด "ไม่มีไฟล์หรือไดเรกทอรีดังกล่าว" จำนวนมาก และไฟล์เหล่านั้นถูกข้ามไปและไม่ได้รับการตรวจสอบ

มีความคิดอะไรบ้าง?


macos bash shell find bootcamp
person Clam    schedule 15.01.2015    source แหล่งที่มา
comment
มันบ่นเกี่ยวกับไฟล์ที่ขึ้นต้นด้วย 0154 เมื่อคุณใช้ชื่อรูปแบบ 0153* หรือไม่? ฉันคิดว่ามันคงไม่ต้องตรวจสอบประเภทด้วยซ้ำ เนื่องจากชื่อไม่ตรงกับรูปแบบ ความคิดอื่นๆ: ไดรฟ์ภายนอกใช้ระบบไฟล์ใด ไปป์เอาต์พุตและ stderr ของคำสั่ง find เหล่านั้นผ่าน hexdump -C และเปรียบเทียบไบต์ของชื่อไฟล์ในทั้งสองกรณี เปรียบเทียบกับการถ่ายโอนข้อมูลฐานสิบหกของเอาต์พุตของ ls ในไดเร็กทอรีเดียวกันนั้นด้วย   -  person Ken Thomases    schedule 16.01.2015
comment
ใช่มันบ่น!!!! ให้ฉันลองข้อเสนอแนะของคุณ   -  person Clam    schedule 16.01.2015
comment
ลอง export LC_TYPE=C ก่อนวิ่ง find อาจจะ   -  person Mark Setchell    schedule 16.01.2015
comment
ยากที่จะแสดงการตอบกลับที่จัดรูปแบบ แต่คุณกำลังทำอะไรบางอย่างกับระบบไฟล์ ไฟล์อยู่ในไดรฟ์ NTFS แต่ข้อผิดพลาดจะไม่เกิดขึ้นหากไฟล์ถูกคัดลอกในเครื่อง (HFS) Hexdump แสดงค่าเดียวกันคือ 65 cc 80 ไม่ว่าไฟล์จะอยู่ในไดรฟ์ HFS หรือ NTFS จริงๆ แล้วฉันประสบปัญหาบางอย่างเพราะ ls 0154* บนไดรฟ์ NTFS ก็ล้มเหลวเช่นกัน ดังนั้นฉันจึงต้องใช้ find โดยไม่มี -type f   -  person Clam    schedule 16.01.2015
comment
export LC_TYPE=Cไม่ได้ช่วยอะไร   -  person Clam    schedule 16.01.2015
comment
ลองใช้ ls ในไดเร็กทอรี โดยไม่มีรูปแบบ glob แน่นอนว่าคุณจะต้องค้นหาไฟล์ hex dump หรือคุณสามารถกรองด้วย grep ก่อนที่จะไพพ์ลงใน hexdump -C เช่น. ls | grep 0154 | hexdump -C.   -  person Ken Thomases    schedule 16.01.2015
comment
@Clam บางทีคุณอาจเขียนทับ find อย่างใด ลอง command find ...   -  person Reinstate Monica Please    schedule 16.01.2015
comment
@KenThomases: คุณพูดถูกเกี่ยวกับระบบไฟล์ ฉันดูโฟลเดอร์ในเครื่อง Windows ไฟล์ปรากฏขึ้นใน Explorer และเปิดใน Windows Photo Viewer md5summer แม้ว่าจะไม่สามารถจัดการได้ ฉันคัดลอกชื่อไฟล์จาก Explorer ลงในแผ่นจดบันทึก และพบว่ามีการใช้อักขระ Unicode สำหรับ E-grave ฉันแทนที่สิ่งนี้ด้วยเวอร์ชัน ASCII ปกติ (ไบต์: 0xE8) และวิธีนี้ช่วยแก้ไขปัญหาสำหรับไฟล์ภายใต้ OS X สิ่งที่ตลกคือ hexdump -C แสดงลำดับอักขระ UTF-8 เดียวกันสำหรับชื่อไฟล์ที่เสียหายและแก้ไขแล้ว: 65 cc 80   -  person Clam    schedule 16.01.2015
comment
คุณได้พิจารณาถาม Ask Different บนไซต์ Apple Stack Exchange หรือไม่   -  person Jonathan Leffler    schedule 16.01.2015

คำตอบ (1)


arrow_upward
0
arrow_downward

ฉันไม่มีวิธีแก้ปัญหา แต่ฉันมีวิธีแก้ไข: อย่าคัดลอกไฟล์จากไดรฟ์ HFS ไปยัง NTFS โดยใช้ไดรเวอร์ HFS ของ Apple (ใน Bootcamp) แต่ทำผ่าน SMB หรือโฟลเดอร์แชร์ของ VMWare Fusion (SMB อย่างมีประสิทธิภาพ ?)

มีสองวิธีในการสร้างตัวละคร e-grave หนึ่งคือการใช้ ASCII 0xE8 แบบขยายจาก CP1252 อีกอันที่ฉันเพิ่งเรียนรู้คือเห็นได้ชัดว่าใช้ Unicode ไบต์ 0x0065 (ตัวอักษรปกติ 'e', ​​ASCII 0x65) + 0x0300 (รวมสำเนียงที่หนักแน่น)

เมื่อฉันคัดลอกไฟล์ใน Bootcamp ชื่อไฟล์จะมีลำดับไบต์ UTF-16le 0x65 0x00 0x00 0x03 (ตัวอักษรปกติ 'e' + การรวมสำเนียงที่หนักแน่น)

เมื่อฉันคัดลอกไฟล์ใน VMWare fusion โดยโฟลเดอร์แชร์ของ VMWare หรือผ่านการแชร์ไฟล์ ชื่อไฟล์จะมีลำดับไบต์ UTF-16le 0xE800 (Windows Code Page 1252 ขยายอักขระ e-grave ASCII ที่ขยาย)

ย้อนกลับไปภายใต้ OS X การไพพ์เอาต์พุตของ find ถึง hexdump -C จะให้ลำดับไบต์ UTF-8 เหมือนกันสำหรับตัวแปรทั้งสองของอักขระนี้: 65 cc 80 นี่อาจเป็นเหตุผลว่าทำไมสิ่งต่าง ๆ ถึงแตกสลายสำหรับฉันภายใต้ OS X

person Clam    schedule 16.01.2015