Dysk zewnętrzny, nie można opróżnić kosza, rm widzi plik, ale ls -la nie

9

Wyczyściłem folder z muzyką na dysku zewnętrznym i znalazłem katalog, którego nie mogę usunąć bez względu na to, co spróbuję.

Jeśli umieszczę go w koszu za pomocą GUI

Operacji nie można ukończyć, ponieważ element „folder” jest w użyciu.

Jeśli rm -rfużyję go do usunięcia za pomocą terminala

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

Jeśli użyję ls -lado sprawdzenia jego zawartości

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

Jeśli używam rm -i *w folderze

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

Jeśli sudo lsof +D folder/sprawdzę, czy jakieś pliki są otwarte

Nic nie zwraca po wyjściu z programu.

Jeśli użyję Narzędzia dyskowego do naprawy dysku i woluminu (pierwsza pomoc)

Kontrola zdrowia przeszła pomyślnie, więc nie rozpoczęto naprawy.

Jeśli zrestartuję macOS

Problem nadal występuje.

Dodatkowe informacje:

  • Mogę przenieść folder na dysku, ale nie na inny dysk.

  • Mogę zmienić nazwę folderu.

  • ls -i *.mp3zwraca ls: 03 - Ēlusion.mp3: No such file or directory, tak samo jak rm -i *.mp3.

  • Plik nie pojawia się w Finderze, co jest mylące, bez względu na to, jaki problem z wyświetlaniem nazwy pliku mógł mieć Terminal (zawsze ustawiałem go na używanie Unicode - UTF-8), myślę, że w grze jest więcej siły.

W odpowiedzi na pytania ls -ibnie , nic nie zwraca.

$ 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 ..

Najwyraźniej jest w tym coś , ale ls -lanie można tego zobaczyć, a rm -inazwa pliku jest dziwna?

get info menu kontekstowe GUI potwierdziło, że w folderze znajduje się 1 element, ale z zerowym bajtem iz pewnością nie pojawia się w wyszukiwarce.

Nie jestem pewien, co mam teraz zrobić. Pomoc bardzo ceniona!

(Korzystanie z 10.13.4 + ExFAT na dysku zewnętrznym)

bitinn
źródło
1
Czy zastanawiałeś się nad utworzeniem kopii zapasowej wszystkich rzeczy, które chcesz - prawdopodobnie i tak już utworzyłeś kopię zapasową ... a następnie całkowicie sformatowaniem tego dysku, aby zacząć od nowa?
Solar Mike
Czy ls -bpokazuje plik? Jeśli tak, możesz ls -bipobrać i-węzeł i postępować zgodnie z poniższą odpowiedzią lub po prostu skopiować nazwę pliku na -bwyjściu.
Reid
Uważam, że głównym problemem nie jest nazwa pliku, ls -bi *.mp3pokaż ten sam wynik, jak pokazano w OP.
bitinn

Odpowiedzi:

10

Problem wydaje się być spowodowany plikiem o nazwie 03 - .mlusion.mp3 znajdującym się w katalogu o nazwie folder .

Ponieważ Terminal.app nie jest w stanie wyświetlać znaków diakrytycznych w nazwach plików - to prawda, ale wykracza to poza najprostsze rozwiązanie - ukrywa swoją awarię poprzez ukrywanie nazwy pliku (coś, co do tej pory nie było dla mnie znane) ; być może zmiany w High Sierra w / .plikie, /. wilkach i 64-bitowych i-węzłach? Czekaj - nieważne; twoja edycja pytania mówi mi, że cię źle zrozumiałem.) W każdym razie, istnienie pliku jest znane, podobnie jak ironia twierdzenie Findera, że ​​nie istnieje. Oczywiście, że tak. Oto jak to zmienić:

Najpierw określ numer i-węzła pliku. W Terminal.app przejdź cddo katalogu „folder” i wydaj polecenie:ls -i *.mp3

Skopiuj ciąg liczbowy i-węzła podany w lewej kolumnie odpowiedzi, co będzie podobne

12345678 03 - E ̄lusion.mp3

- i wstaw go do tego polecenia, które zmieni nazwę na coś, co terminal może poprawnie renderować:

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

- dając ci plik „deletemenow” w folderze „folder”, z których oba możesz pozbyć się w sposób, który najbardziej ci odpowiada.

Doc G.
źródło
Wow, to imponująco okropny błąd.
Chrylis -on strike-
2
Nie sądzę, żeby to było poprawne. Terminal może ukrywać pojedyncze znaki, których nie może renderować, ale nie usunie całego wiersza tekstu.
duskwuff -inactive-
1
@duskwuff Tak czy inaczej, wydaje się, że nazwa pliku powoduje problemy, więc jest to potencjalne rozwiązanie niezależnie od tego.
JAB
Przepraszamy, ale problem wydaje się bardziej skomplikowany: próbowałem $ ls -i *.mp3, powraca ls: 03 - Ēlusion.mp3: No such file or directory.
bitinn
1
Czy możesz po prostu uruchomić ls -iw katalogu, aby zapobiec zakłócaniu interpretacji symboli zastępczych przez powłokę?
nohillside
9

Długo zajęło mi dotarcie do tego podsumowania, ale myślę, że to ostateczna odpowiedź.

Przyczyna mojego problemu jest dobrze znana :

OS X jest dziwny, zarówno dlatego, że normalizuje nazwy plików, jak i używa NFD zamiast bardziej powszechnego NFC .

Historycznie (nie tak dawno, przed 10.11), OS X + HFS + wymusza formularz NFD na wszystkich nazwach plików , a wynik NFD otrzymujesz tylko z poleceń i wywołań systemowych.

Potem wszystko zaczyna się zmieniać, w 10.11 niektóre wyniki wywołania systemowego są znormalizowane do NFC , co sprawia, że ​​jest to zgodne z Windows i Linux, ale kosztem złamania niektórych programów, które oczekują NFD w OS X.

Ale od czasu wprowadzenia systemu macOS 10.13 + AFPS zachowanie zmienia się ponownie: Apple decyduje, że chce się znormalizować do NFD na wyświetlaczu i wywołaniach systemowych , ale pozostawia oryginalne nazwy plików bez zmian (więc obsługiwane są zarówno NFC, jak i NFD, ale jeśli wybierzesz nazwa pliku w Finderze lub skopiuj lswynik w Terminalu, otrzymasz formularz NFD).

To wszystko świetnie, dopóki nie umieścisz pliku z nazwą pliku NFD na dysku zewnętrznym za pomocą exFAT (ponieważ jest to jedyny format cross-macOS / Windows z obsługą rozmiaru pliku 4 GB +): macOS 10.13 jakoś wierzy, że twój plik musi być w formacie NFC, więc wypalił się.

Oto szybki test, mam folder w systemie Windows na dysku exFAT z 3 plikami:

wprowadź opis zdjęcia tutaj

  • test.mp3
  • Ēlusion.mp3( Ēw NFC)
  • 03 - Ēlusion( Ēw NFD)

(Możesz skopiować dokładny kod Unicode tutaj )

Kiedy montuję je na moim systemie macOS, widzę to:

wprowadź opis zdjęcia tutaj

i ls -laibwynik:

$ 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

Jak widać, plik NFC jest obecny, ale brakuje pliku NFD.

Nawet jeśli zdajesz sobie sprawę z problemu NFC / NFD w systemie OS X , możesz nie oczekiwać, że dysk zewnętrzny exFAT napotka ten problem w odwrotny sposób (NFC jest w porządku, ale NFD jest w ogniu).

Ale co mogło spowodować, że mój plik muzyczny używał nazwy pliku NFD:

  • Pierwotnie pobrałem ten plik muzyczny w wersji 10.9 / 10.10 ze starszym komputerem Mac, który wymusza nazwę pliku NFD.
  • W pewnym momencie przenoszę je na dysk Windows + NTFS, który nie wymusza NFC / NFD, więc zachowana jest oryginalna nazwa pliku NFD.
  • Teraz chcę przenieść ten plik z powrotem do mojego systemu macOS 10.13 + APFS przy użyciu dysku exFAT (exFAT obsługuje tę samą konwencję UTF-16 co NTFS).
  • Rozpęta się piekło.

Mógłbym skopiować plik przez dysk sieciowy lub TeamViewer, i byłoby dobrze, ale exFAT powoduje ten błąd na macOS.

Lekcje:

  • Nazwa pliku Unicode nadal stanowi zagrożenie.
  • W rzeczywistości potrzebujesz systemu Windows / Linux, aby rozwiązać ten problem (jeśli sytuacja jest taka, że ​​Twój plik znajduje się na dysku zewnętrznym exFAT).
bitinn
źródło
@bitlinn: Kliknij drugi link w moim komentarzu skierowanym do duskwulff i wypróbuj narzędzie normalizacji Unicode Apfelstrudel, które tam znajdziesz. Bardzo przydatne dla APFS, bezcelowe z exFAT. Albo to jest...?
Doc G.
1
@DocG. ten problem jest nieco bardziej złożony, niż początkowo myślałem, ale ponownie zaktualizowałem swoją odpowiedź!
bitinn
Tak, myślałem, że możesz to zrobić. Zobacz mój wcześniejszy komentarz Error 36i wyszukaj w sieci coś takiego jak „przenieś pliki tam iz powrotem Windows mac error 36”, aby uzyskać więcej informacji na temat rozdzielania atrybutów plików w systemach innych niż HFS. Jest to (inny) znany problem nazewnictwa plików w systemie MacOS / OS X od czasu pojawienia się Systemu 10.6. Między normalizacją Unicode a separacją atrybutów dot_underscore wystąpił cholerny podwójny błąd. Wątpię, czy polecenie dot_clean miało szansę.
Doc G.