Ổ đĩa ngoài, không thể đổ rác, rm thấy một tệp, nhưng ls -la thì không


9

Tôi đã xóa một thư mục nhạc trong ổ đĩa ngoài và tìm thấy một thư mục tôi không thể xóa bất kể tôi có cố gắng gì.

Nếu tôi bỏ nó vào thùng rác thông qua GUI

Thao tác không thể hoàn tất vì mục thư mục này được sử dụng.

Nếu tôi sử dụng rm -rfđể loại bỏ nó qua thiết bị đầu cuối

$ rm -rf folder/
rm: folder/: Directory not empty

Nếu tôi sử dụng ls -lađể kiểm tra nội dung của nó

$ ls -la
total 512
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

Nếu tôi sử dụng rm -i *trong thư mục

$ rm -i *
rm: 03 - Ēlusion.mp3: No such file or directory

Nếu tôi sử dụng sudo lsof +D folder/để kiểm tra xem có tập tin nào được mở không

Không có gì trở lại khi thoát khỏi chương trình.

Nếu tôi sử dụng Disk Utility để sửa chữa (ổ sơ cứu) đĩa và ổ đĩa

Kiểm tra sức khỏe thông qua để không sửa chữa được bắt đầu.

Nếu tôi khởi động lại macOS

Vấn đề vẫn tồn tại.

Thông tin bổ sung:

  • Tôi có thể di chuyển thư mục trong ổ đĩa, nhưng không chuyển sang ổ đĩa khác.

  • Tôi có thể đổi tên thư mục.

  • ls -i *.mp3trả lại ls: 03 - Ēlusion.mp3: No such file or directory, giống như rm -i *.mp3.

  • Tệp không hiển thị trong Finder, đó là phần khó hiểu, bất kể vấn đề hiển thị tên tệp nào mà Terminal có thể có (tôi luôn đặt nó để sử dụng Unicode - UTF-8), tôi nghĩ rằng có nhiều lực hơn khi chơi.

Để trả lời các câu hỏi, ls -ibkhông , không trả lại bất cứ điều gì.

$ ls -i
$ ls -ib
$ ls -laib
total 512
2762318 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff  131072 Jan  3  2017 ..

Vì vậy, rõ ràng có một cái gì đó trong đó nhưng ls -lakhông thể nhìn thấy nó, trong khi rm -ilà lạ với tên tệp?

get info thông qua menu ngữ cảnh GUI đã xác nhận có 1 mục trong thư mục, nhưng với byte bằng 0 và chắc chắn không hiển thị trong công cụ tìm.

Tôi không chắc phải làm gì vào thời điểm này. Giúp nhiều đánh giá cao!

(Sử dụng 10.13.4 + ExFAT trên ổ đĩa ngoài)


1
Bạn đã xem xét sao lưu tất cả những thứ bạn muốn - dù sao cũng có thể đã sao lưu ... sau đó định dạng lại hoàn toàn ổ đĩa đó để bắt đầu lại?
Năng lượng mặt trời Mike

ls -bhiển thị các tập tin? Nếu vậy, bạn có thể ls -bilấy inode và làm theo câu trả lời bên dưới, hoặc thay thế chỉ cần sao chép tên tệp trong -bđầu ra.
Reid

Tôi tin rằng vấn đề cốt lõi không nằm ở tên tệp, ls -bi *.mp3hiển thị kết quả tương tự như trong OP.
bitinn

Câu trả lời:


10

Sự cố dường như được gây ra bởi một tệp có tên 03 - Ēlusion.mp3 nằm trong thư mục có tên thư mục .

Bởi vì Terminal.app không thể hiển thị dấu phụ trong tên tệp - tốt, nhưng nó vượt quá phạm vi cung cấp giải pháp đơn giản nhất cho bạn - nó che giấu sự thất bại của nó bằng cách ẩn tên tệp (trước đây chưa từng nghe thấy ; có lẽ các thay đổi của High Sierra đối với /.file, /.volfs và 64-bit? Đợi-- đừng bận tâm, chỉnh sửa câu hỏi của bạn cho tôi biết tôi đã hiểu nhầm bạn.) Dù sao, sự tồn tại của tệp được biết đến, cùng với sự mỉa mai ganh đua bởi Finder mà nó không tồn tại. Rõ ràng, nó làm. Đây là cách thay đổi điều đó:

Đầu tiên, xác định số inode của tập tin. Trong Terminal.app, cdvào thư mục "thư mục" và đưa ra lệnh này:ls -i *.mp3

Sao chép chuỗi số của nút được cung cấp trong cột bên trái của phản hồi, sẽ giống như

12345678 03 - E ̄lusion.mp3

- và đặt nó vào lệnh này, nó sẽ đổi tên nó thành một cái gì đó mà thiết bị đầu cuối có thể kết xuất chính xác:

find . -inum 12345678 -exec mv {} deletemenow \;

- cung cấp cho bạn tệp "xóa" trong thư mục "thư mục", cả hai tệp bạn có thể loại bỏ theo bất kỳ cách nào phù hợp nhất với sở thích của bạn.


Wow, đó là một lỗi ấn tượng khủng khiếp.
chrylis -on đình công-

2
Tôi không nghĩ rằng điều này là chính xác. Thiết bị đầu cuối có thể ẩn các ký tự đơn mà nó không thể hiển thị, nhưng nó sẽ không xóa toàn bộ dòng văn bản.
duskwuff -inactive-

1
@duskwuff Dù bằng cách nào, có vẻ như tên tệp đang gây ra sự cố, vì vậy đây là một giải pháp tiềm năng bất kể.
JAB

Xin lỗi nhưng vấn đề có vẻ phức tạp hơn thế này: Tôi đã thử $ ls -i *.mp3, nó sẽ trả lại ls: 03 - Ēlusion.mp3: No such file or directory.
bitinn

1
Bạn có thể chạy ls -itrong thư mục để ngăn chặn sự mở rộng ký tự đại diện không?
nohillside

9

Tôi đã mất một thời gian dài để đi đến bản tóm tắt này, nhưng tôi nghĩ đó là câu trả lời dứt khoát.

Nguyên nhân của vấn đề của tôi là một vấn đề nổi tiếng :

OS X là một số lẻ, cả ở chỗ nó bình thường hóa tên tệp và trong đó nó sử dụng NFD thay vì NFC phổ biến hơn .

Trong lịch sử (không phải là cũ, trước thời đại 10.11), OS X + HFS + thi hành biểu mẫu NFD trên tất cả các tên tệp và bạn sẽ chỉ nhận được kết quả NFD từ các lệnh và lệnh gọi hệ thống.

Sau đó, mọi thứ bắt đầu thay đổi, vào ngày 10.11, một số kết quả cuộc gọi hệ thống được chuẩn hóa thành NFC , điều này đặt nó phù hợp với Windows và Linux, nhưng phải trả giá bằng việc phá vỡ một số chương trình mong đợi NFD trên OS X.

Nhưng kể từ khi giới thiệu macOS 10.13 + AFPS, hành vi lại thay đổi: Apple quyết định muốn bình thường hóa thành NFD trên màn hình và các cuộc gọi hệ thống , nhưng để nguyên tên tệp gốc (vì vậy cả NFC và NFD đều được hỗ trợ, nhưng nếu bạn chọn tên tệp trong Finder hoặc sao chép lskết quả trong Terminal, bạn nhận được biểu mẫu NFD).

Điều này thật tuyệt vời, cho đến khi bạn đặt một tệp có tên tệp NFD vào ổ đĩa ngoài bằng exFAT (vì đó là định dạng chéo macOS / Windows duy nhất có hỗ trợ kích thước tệp 4GB +): macOS 10.13 bằng cách nào đó tin rằng tệp của bạn phải ở định dạng NFC, vì vậy nó ngoạm ra.

Trên thực tế, đây là một thử nghiệm nhanh, tôi có một thư mục trong Windows trên ổ đĩa exFAT của mình với 3 tệp:

nhập mô tả hình ảnh ở đây

  • test.mp3
  • Ēlusion.mp3( Ēbằng NFC)
  • 03 - Ēlusion( Ētrong NFD)

(Bạn có thể sao chép unicode chính xác tại đây )

Khi tôi gắn chúng trên macOS của mình, đây là những gì tôi thấy:

nhập mô tả hình ảnh ở đây

ls -laibkết quả:

$ ls -laib
total 46592
2762318 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 .
2685260 drwxrwxrwx  1 user  staff    131072 Jan  3  2017 ..
1572961 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 Ēlusion.mp3
1572871 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 test.mp3

Như bạn có thể thấy, tệp NFC có mặt nhưng tệp NFD bị thiếu.

Ngay cả khi bạn nhận thức được vấn đề NFC / NFD trên OS X , bạn có thể không mong đợi ổ đĩa ngoài exFAT phải đối mặt với vấn đề này theo cách ngược lại (NFC vẫn ổn, nhưng NFD đang hoạt động).

Nhưng điều gì có thể khiến tệp nhạc của tôi sử dụng tên tệp NFD ở vị trí đầu tiên:

  • Ban đầu tôi đã tải xuống tệp nhạc này vào ngày 10.9 / 10.10 với máy Mac cũ hơn, thực thi tên tệp NFD.
  • Tại một số thời điểm, tôi chuyển chúng sang ổ đĩa Windows + NTFS, không thực thi NFC / NFD, vì vậy tên tệp NFD ban đầu được giữ nguyên.
  • Bây giờ tôi muốn chuyển tệp này trở lại macOS 10.13 + APFS của mình bằng ổ exFAT (exFAT hỗ trợ quy ước UTF-16 tương tự như NTFS).
  • Địa ngục vỡ ra.

Tôi có thể đã sao chép tệp qua ổ đĩa nối mạng hoặc TeamViewer và nó sẽ ổn, nhưng exFAT đang kích hoạt lỗi này trên macOS.

Những bài học:

  • Tên tệp Unicode vẫn là một mối đe dọa.
  • Bạn thực sự cần một Windows / Linux để khắc phục vấn đề này (nếu tình huống là tệp của bạn nằm trên ổ đĩa ngoài exFAT).

@bitlinn: Nhấp vào liên kết thứ hai trong bình luận của tôi gửi đến duskwulff và dùng thử công cụ chuẩn hóa unicode Apfelstrudel bạn sẽ tìm thấy ở đó. Rất hữu ích cho APFS, vô nghĩa với exFAT. Hoặc là nó...?
Đốc G.

1
@DocG. vấn đề này phức tạp hơn một chút so với tôi nghĩ ban đầu, nhưng tôi đã cập nhật lại câu trả lời của mình!
bitinn

Vâng, tôi nghĩ rằng bạn có thể sẽ làm điều đó. Xem nhận xét trước đó của tôi về Error 36và thực hiện tìm kiếm trên web cho một cái gì đó như "di chuyển tệp qua lại windows mac error 36" để biết thêm thông tin về cách tách các phân bổ tệp trên các hệ thống không phải HFS. Điều này đã được (một) vấn đề đặt tên tệp MacOS / OS X được biết đến kể từ khi Hệ thống 10.6 xuất hiện. Giữa chuẩn hóa Unicode và phân tách thuộc tính dot_underscore, bạn đã gặp phải một lỗi kép. Tôi nghi ngờ nếu lệnh dot_clean có cơ hội.
Đốc G.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.