Unità esterna, impossibile svuotare il cestino, rm vede un file, ma ls -la no

Stavo cancellando una cartella musicale nel mio disco esterno e ho trovato una directory che non posso cancellare, qualunque cosa provi.

Se lo metto nel cestino tramite la GUI

L'operazione non può essere completata perché la voce "cartella" è in uso.

Se lo uso rm -rfper rimuoverlo tramite terminale

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

Se lo utilizzo ls -laper verificarne il contenuto

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

Se uso rm -i *all'interno della cartella

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

Se uso sudo lsof +D folder/per verificare se sono stati aperti file

Nulla ritorna all'uscita dal programma.

Se uso Utility Disco per riparare (primo soccorso) il disco e il volume

Il controllo dello stato è stato superato, quindi non è stata avviata alcuna riparazione.

Se riavvio macOS

Il problema persiste.

Informazioni addizionali:

Posso spostare la cartella all'interno dell'unità, ma non su un'altra unità.
Posso rinominare la cartella.
ls -i *.mp3ritorna ls: 03 - Ēlusion.mp3: No such file or directory, lo stesso di rm -i *.mp3.
Il file non viene visualizzato in Finder, è una parte confusa, qualunque sia il problema di visualizzazione del nome file che Terminal potrebbe avere (l'ho sempre impostato per l'uso Unicode - UTF-8), penso che ci sia più forza in gioco.

In risposta alle domande, ls -ibno , non restituisce nulla.

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

Quindi, a quanto pare, c'è qualcosa in esso, ma ls -lanon riesco a vederlo, mentre rm -iè strano con il nome del file?

get info tramite il menu contestuale della GUI ha confermato che c'è 1 elemento nella cartella, ma con zero byte, e certamente non compare nel finder.

Non sono sicuro di cosa fare a questo punto. Aiuto molto apprezzato!

(Usando 10.13.4 + ExFAT su disco esterno)

— bitinn
fonte

Hai preso in considerazione il backup di tutte le cose che vuoi - probabilmente già il backup comunque ... quindi riformattare completamente quell'unità per ricominciare?

— Solar Mike,

Non ls -bmostrare il file? In tal caso, è possibile ls -biottenere l'inode e seguire la risposta di seguito, oppure in alternativa semplicemente copiare il nome file -bnell'output.

— Reid,

Credo che il problema principale non sia con il nome file, ls -bi *.mp3mostra lo stesso risultato mostrato in OP.

— Bitinn,

Risposte:

Il problema sembra essere causato da un file denominato 03 - Ēlusion.mp3 situato nella directory denominata cartella .

Poiché Terminal.app non è in grado di eseguire il rendering dei segni diacritici nei nomi dei file - beh, lo è, ma questo va oltre lo scopo di fornire la soluzione più semplice per te - nasconde il suo fallimento nascondendo il nome del file (qualcosa di inaudito da me prima d'ora ; forse la sua High Sierra cambia in /.file, /.volfs e inode a 64 bit? Aspetta-- non importa; la tua modifica alla tua domanda mi dice che ti ho frainteso.) Comunque, l'esistenza del file è nota, insieme all'ironico contesa del Finder che non esiste. Ovviamente, lo fa. Ecco come cambiarlo:

Innanzitutto, determinare il numero di inode del file. In Terminal.app, cdnella directory "cartella" ed emettere questo comando:ls -i *.mp3

Copia la stringa numerica dell'inode fornita nella colonna di sinistra della risposta, che sarà simile

12345678 03 - E ̄lusion.mp3

--e lo inserisce in questo comando, che lo rinomina in qualcosa che il terminale può visualizzare correttamente:

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

- dandoti il file "cancella" nella cartella "cartella", entrambi i quali potresti disporre nel modo che preferisci.

— Doc G.
fonte

Wow, questo è un bug incredibilmente terribile.

— Chrylis

Non penso sia accurato. Il terminale può nascondere singoli caratteri che non può essere visualizzato, ma non rimuoverà l'intera riga di testo.

— duskwuff -inattivo-

@duskwuff In entrambi i casi sembra che il nome del file stia causando problemi, quindi questa è una potenziale soluzione a prescindere.

— JAB

Scusate ma il problema sembra più complesso di così: ho provato $ ls -i *.mp3, ritorna ls: 03 - Ēlusion.mp3: No such file or directory.

— Bitinn,

Puoi semplicemente eseguire ls -inella directory per impedire che l'espansione dei caratteri jolly della shell interferisca?

— Nohillside

Mi ci è voluto molto tempo per arrivare a questo riassunto, ma penso che sia la risposta definitiva.

La causa del mio problema è ben nota :

OS X è quello strano, sia per il fatto che normalizza i nomi dei file sia per il fatto che utilizza NFD invece del più comune NFC .

Storicamente (non così vecchio, prima dell'era 10.11), OS X + HFS + impone il modulo NFD su tutti i nomi di file e otterrai solo risultati NFD da comandi e chiamate di sistema.

Quindi le cose iniziano a cambiare, in 10.11, alcuni risultati delle chiamate di sistema sono normalizzati in NFC , il che lo mette in linea con Windows e Linux, ma a spese di interrompere alcuni programmi che prevedono NFD su OS X.

Ma dall'introduzione di macOS 10.13 + AFPS, il comportamento cambia di nuovo: Apple decide di voler normalizzare NFD su display e chiamate di sistema , ma lascia i nomi dei file originali così come sono (quindi sono supportati sia NFC che NFD, ma se selezioni il nome del file nel Finder o copia il lsrisultato nel Terminale, ottieni il modulo NFD).

Tutto questo è fantastico, fino a quando non inserisci un file con nome file NFD in un'unità esterna usando exFAT (poiché è l'unico formato cross-macOS / Windows con supporto dimensioni file 4 GB +): macOS 10.13 in qualche modo crede che il tuo file debba essere in formato NFC, quindi è scoppiato.

In effetti, ecco un breve test, ho una cartella in Windows sul mio disco exFAT con 3 file:

test.mp3
Ēlusion.mp3( Ēin NFC)
03 - Ēlusion( Ēin NFD)

(Puoi copiare l'esatto Unicode qui )

Quando li monto sul mio macOS, questo è quello che vedo:

e ls -laibrisultato:

$ 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 Ēlusion.mp3
1572871 -rwxrwxrwx  1 user  staff  11672464 Aug 23  2014 test.mp3

Come puoi vedere, il file NFC è presente ma manca il file NFD.

Anche se sei a conoscenza del problema NFC / NFD su OS X , potresti non aspettarti che l'unità esterna exFAT affronti questo problema in modo opposto (NFC va bene, ma NFD è pant-on-fire).

Ma cosa potrebbe aver fatto sì che il mio file musicale usasse il nome file NFD in primo luogo:

Originariamente ho scaricato questo file musicale il 10.9 / 10.10 con un Mac più vecchio, che applica il nome file NFD.
Ad un certo punto li sposto su un'unità Windows + NTFS, che non impone NFC / NFD, quindi il nome file NFD originale viene conservato.
Ora voglio spostare nuovamente questo file su macOS 10.13 + APFS usando un'unità exFAT (exFAT supporta la stessa convenzione UTF-16 di NTFS).
L'inferno si scatena.

Avrei potuto copiare il file tramite unità di rete o TeamViewer, e andrebbe bene, ma exFAT sta attivando questo bug su macOS.

Lezioni:

Il nome file Unicode è ancora una minaccia.
In realtà hai bisogno di un Windows / Linux per risolvere questo problema (se la situazione è che il tuo file si trova su un'unità esterna exFAT).

— bitinn
fonte

@bitlinn: fai clic sul secondo link nel mio commento indirizzato a duskwulff e prova lo strumento di normalizzazione unicode di Apfelstrudel che troverai lì. Molto utile per APFS, inutile con exFAT. O è...?

— Doc G.

@DocG. questo problema è un po 'più complesso di quanto pensassi inizialmente, ma ho aggiornato di nuovo la mia risposta!

— Bitinn,

Sì, ho pensato che potresti finire per farlo. Guarda il mio commento precedente su Error 36e fai una ricerca sul web per qualcosa come "sposta i file avanti e indietro di Windows mac errore 36" per ulteriori informazioni sulla separazione delle attribuzioni dei file su sistemi non HFS. Questo è stato (un altro) noto problema di denominazione dei file MacOS / OS X dall'arrivo di System 10.6. Tra la normalizzazione Unicode e la separazione dell'attributo dot_underscore, hai riscontrato un doppio errore. Dubito che il comando dot_clean avesse una possibilità.

— Doc G.