Prova a eliminare la directory con "rm -rf", ma ricevi un messaggio che non è vuoto


30

Ho provato a cancellare una directory usando "rm -rf" e ricevo il messaggio "Directory non vuota":

Bens-MacBook-Pro:please benjaminhocking$ ls -lart empty_directory/
total 16
drwxr-xr-x  5 benjaminhocking  staff  170 Aug 27 14:46 .
drwxr-xr-x  3 benjaminhocking  staff  102 Aug 27 15:28 ..
Bens-MacBook-Pro:please benjaminhocking$ rm -rf empty_directory/
rm: empty_directory/: Directory not empty
Bens-MacBook-Pro:please benjaminhocking$ rmdir empty_directory/
rmdir: empty_directory/: Directory not empty

Se provo la stessa cosa usando Finder (trascinando la cartella nel Cestino), ricevo il messaggio

L'operazione non può essere completata perché è in uso l'elemento "directory_vuota".

Ho provato a farlo xattr -d com.apple.quarantine, puramente per superstizione, ma non ha funzionato.

Un pezzo di contesto probabilmente importante è che questa directory era inizialmente in una directory che avrebbe dovuto essere eliminata da un comando "make clean" che avevo emesso prima che il Terminale mi bloccasse, dopo di che poco più della metà degli altri programmi che avevo in esecuzione anche bloccato, incluso Skype, e infine il sistema operativo stesso. Ho finito per riavviare il computer tenendo premuto il tasto di accensione.

Modifica per aggiungere: Un'altra importante informazione che ho lasciato fuori era che ciò stava accadendo in una cartella crittografata à la encfs. Sono stato in grado di rintracciare la cartella corrispondente nel lato crittografato delle cose ed eliminarla lì. Ancora non so perché non potrei farlo dal lato decifrato di cose come faccio normalmente. Lascerò questo senza risposta per ora nel caso qualcuno abbia una buona risposta per questo.


2
Hai qualche altra shell aperta all'interno di questa directory o un'app in esecuzione che la utilizza? Il termine "è in uso" potrebbe anche significare che (anche se non ho mai sperimentato di non essere in grado di rmdirfarlo - ma spesso è la causa per cui non è possibile smontare un volume).
Izzy,

Al momento non erano stati emessi quei comandi particolari. Avevo fatto un riavvio completo poco prima di quello.
Ben Hocking,

A volte ho lo stesso problema con EncFS e finora non ho idea di come risolverlo. Nulla di nuovo?
Martin Preusse,

@emempe: Quello che alla fine ho fatto è stato cancellare la cartella nello spazio crittografato, usando l'ultimo timestamp modificato come mio identificatore. (Che può essere pericoloso.) Se trovo una soluzione migliore, te lo farò sapere.
Ben Hocking,

@BenHocking: lo faccio anche io. Succede raramente per me, quindi sto bene con questo. Tuttavia, non mi piace la sensazione che il mio EncFS sia stato corrotto in qualche modo ...;) Il mio EncFS è in un Dropbox, forse qualche connessione?
Martin Preusse,

Risposte:


10

Riavvia il computer ed esegui di rmdir(1)nuovo.

$ rmdir -r empty_directory/

Se il problema persiste, prova:

$ rm -rf empty_directory/

Se il problema persiste, supponendo che OS X sia lsof(8)preinstallato, quindi immettere:

$ lsof +D empty_directory/

Questo dovrebbe dire se alcuni file in questa directory vengono utilizzati da qualsiasi programma. Penso che il filesystem HFS + non consenta la cancellazione dei file in uso. In killall(1)ogni caso, qualsiasi eseguibile che potrebbe utilizzare questa directory o qualsiasi file nascosto al suo interno. È probabile che Finder stia utilizzando un file nascosto nella empty_directorydirectory per memorizzare le impostazioni di visualizzazione delle cartelle. Spero che sia di aiuto.

PS: per scoprire se lsof(8)è installato, inserisci:

$ lsof

Se l'output è simile al seguente, lsof(8)viene installato sul sistema.

lsof: /usr/bin/lsof /usr/bin/X11/lsof /usr/share/man/man8/lsof.8.gz

Controlla eventuali file nascosti e crittografati o file di chiavi di crittografia in quella directory. Questi potrebbero essere il colpevole.


3

Riparare il disco usando Utility Disco risolve questo problema per me.


Funzionerà nella maggior parte degli scenari in cui credo. Ha funzionato totalmente per me. Grazie
GeekRide il

Il comando specifico è "Esegui pronto soccorso ..." nel menu File. Ho trascorso un po 'troppo tempo a cercare nei menu la parola "riparazione" prima di rendermene conto!
RoG

3

Se ciò accade e sei sicuro di voler eliminare tutto, dovresti provare a utilizzare sudo rm -rf directory/


1
Questo non funziona su ~ / .Trash per qualche motivo.
MarcusJ,

2
Questo in realtà non funziona affatto a meno che il problema non sia costituito dalle autorizzazioni, che sarebbe un messaggio di errore diverso per la console.
Tresf

2

Mi sono imbattuto esattamente in questo errore mentre cercavo anche di rimuovere una directory (rm -r dirname). Avevo già provato tutti i suggerimenti che ho letto qui prima di cercare e trovare questa discussione. Non so se potrebbero esserci stati altri punti involontariamente lasciati non dichiarati dalla domanda originale, ma nel mio caso la radice del problema e la soluzione era:

  • la directory in questione era su un disco montato in rete

  • qualsiasi lstentativo da Finder o dalla riga di comando non mostrava altro che .e..

  • Ho effettuato l'accesso al server del disco di rete tramite il sshcomando e verificato ls -allì. Il risultato ha mostrato, oltre a .e .., diversi .__filenameelementi con informazioni di sicurezza estese (ad esempio, +aggiunte alla modalità).

Credo che queste siano, o sono simili a, i file che ho notato Mac OSX creazione di anni fa quando si usa cp -R, taro cpioper archiviare o spostare gruppi di file. Avevo dedotto al momento che erano usati per ripristinare correttamente alcune proprietà del file dopo lo spostamento - forse uid / gid, mode, acls, mtime / utime / ctime, ecc; Non ne sono davvero sicuro: proprietà che non erano state ripristinate correttamente da quei comandi prima di quel momento (ricordo che OSX includeva mvmace cpmaccomandi per aggirare il problema prima che questi .__filenametipi di file iniziassero ad apparire quando si usavano le solite forme di cp, tar, eccetera).

Non ho mai avuto problemi a eliminare questi file quando erano stati scritti su un'unità interna, USB o Firewire; questa era la prima volta che li trovavo su un disco di rete; completamente non rilevabile dal lato client del mount, ma normale in ogni modo se visto dal lato server.

rm -rf dirname da un login sul server del disco di rete è stata rimossa correttamente la directory insieme al suo contenuto.

Quindi, c'è un'altra risposta per quello che vale; un'altra potenziale soluzione a questo problema se dovesse apparire per chiunque in congiunzione con un disco di rete.


1

A beneficio dei lettori:

Attenzione rm -rfin questo caso! Può creare problemi altrove nel caso in cui si tratti di una condivisione di rete! Sei stato avvertito!

In quasi tutti i casi, se a directorysembra essere vuoto, utilizzare rmdir directoryo forse sudo rmdir directory. Non utilizzare rm(o delsu Windows). Se questo non funziona, è necessario scoprire cosa blocca questa richiesta, risolverlo e quindi riprovare rmdir.

Si prega di notare che non conosco OS-X, ma penso che le cose siano molto simili al comportamento Unix / BSD.

È molto probabile che la directory in questione fosse solo un punto di mount (dagli encfs) o risiedesse su un mount point che divenne di sola lettura o bloccato in uno stato improprio (che impediva la rimozione della directory). Se ora imponi la rimozione della directory, possono succedere cose molto brutte.

Nel migliore dei casi la directory era davvero vuota, quindi rimuoverla (distruggendo il mount ecc.) Non ha fatto ulteriori danni. Nel brutto caso non era vuoto, sembrava solo essere, il che significa che hai spazzato via qualcosa che forse non volevi uccidere. Tutto dipende dal tipo di montaggio, quali driver sono in uso, ecc. Pp.

Se le cose vengono implementate ragionevolmente bene, normalmente non dovrebbe succedere nulla di male. Tuttavia, questo non è il caso normale. Le cose sono già in uno stato strano, il che significa: qualcosa non va, quindi meglio non provare a mescolarlo ulteriormente! Se qualcosa si rompe, qualsiasi tocco sbagliato potrebbe romperlo.

Ad esempio, se si verifica una condizione di competizione su una condivisione di rete, è possibile che vengano rm -rfrimossi i dati che sono stati appena copiati nella condivisione da qualcun altro.

Tuttavia rmdirè garantito per non fare mai del male, oltre a rimuovere directory davvero vuote. Questo è vero anche su NFS, perché NFS garantisce solo un comportamento veramente atomico su mkdire rmdir, ma in nessun altro posto.

PER TUA INFORMAZIONE:

È possibile rilevare un mountpoint utilizzando lo strumento mountpoint directory. In alternativa, guarda l'output di mounte prova a individuare i tuoi supporti lì. Ma attenzione, almeno sotto Linux questo potrebbe mentire. Utilizzo mountpointdell'utilità più affidabile ma meno conveniente.

In tal caso, hai trovato il mountpoint, puoi smontarlo e quindi rimuovere la directory, questa è la seguente sequenza:

umount directory rmdir directory

Se necessario usare sudo, come al solito.

Appunti:

  • Le condivisioni di rete potrebbero negare rmdir(e qualsiasi altra cosa) a causa dei diritti di accesso.

  • I filesystem difettosi possono negare rmdir, a seconda della strategia fallita. Forse vedrai un messaggio ragionevole in quel caso, forse no.

  • Sotto Linux (e probabilmente qualsiasi sistema operativo moderno) puoi anche limitare l'accesso usando mezzi diversi (come montare qualcosa di sola lettura, capacità come in SeLinux, ecc.). Ciò significa quindi che non vedi che è un mountpoint e non vedi nulla di sbagliato, ma semplicemente non funziona. In tal caso, devi cercare qualche altro motivo e può essere sepolto molto profondamente nel sistema operativo. Dipende dallo strumento se viene visualizzato un messaggio di errore ragionevole. Forse anche dare un'occhiata al registro syslog / kernel come dmesgsotto Linux (scusate, non conosco l'equivalente OS-X).

  • Si noti che anche il blocco obbligatorio dei file può essere una fonte. Mentre questo è normale su Windows, di solito non è il caso normale Unix e non l'ho mai sentito per le directory. I blocchi di file obbligatori sono coperti da POSIX, ma sono opzionali.

  • Molto spesso in questi casi, la directory in questione risiede su un filesystem diverso da quello che si pensava. Puoi scoprire quale, con il comando df directory(penso che sia lo stesso in OS-X).

  • Puoi ispezionare più in profondità con strumenti come stato statfsnella directory. Tuttavia, questi sono un livello un po 'basso per le persone normali e abbastanza spesso tali strumenti sono ben nascosti agli utenti normali.

  • Le directory possono avere file con nomi divertenti. Come un file che cancella immediatamente l'output del terminale, quindi sembra che non ci sia. Prova qualcosa di simile ls -al | lesso usa qualcosa di simile a MidnightCommander mc.

Ci sono un sacco di altre possibilità, tra cui bug, haxor, alieni o forse cose più esotiche come le fate. Ma di solito non è saggio iniziare a guardare lì, invece prima cerca di trovare l'errore al tuo fianco, perché "errare humanum est".


1

Questo potrebbe anche essere un caso che ho appena risolto in cui un collegamento simbolico interrotto era sul lato server e non era visibile al client tramite CIFS. Il link simbolico popolava una directory non vuota, ma il client non era in grado di vedere o stat il link simbolico allo scopo di cancellare la directory prima di scollegare la directory. Dato che era invisibile, ha creato questo paradosso dove dal lato client era vuoto ma "non vuoto" su sfida di rm . Se si dispone dell'accesso SSH al server, provare una shell a tale scopo e vedere se la directory è veramente vuota o se potrebbe contenere collegamenti simbolici. Sono stato in grado di farlo su un Drobo5N e mi ha salvato il culo.


Questo potrebbe essere utile per gli altri in una situazione simile, ma sicuramente non è stato il caso per me in quanto non ero collegato a nessun server al momento.
Ben Hocking,

1

Ho provato tutte le risposte qui senza risultati. Sono stato, tuttavia, in grado di spostare la directory da parte usando il comando mv , che mi ha permesso di continuare.


1

L'unica soluzione che ha funzionato per me è stata da https://unix.stackexchange.com/questions/234876/unable-to-delete-a-file-whatever-i-do :

Spostali su / tmp e riavvia.

Le altre opzioni che ho provato sono state:

  • Utility disco - Pronto soccorso.
  • lsof +D bad_file non ha mostrato output.
  • sudo rm -rf
  • Avvio nel terminale per utente singolo e rm -rf.

1
Fsck dal terminale per utente singolo non ha aiutato rm -rf, né lsof +Dmostra nulla. Stranamente, sono stato in grado di spostare le directory offensive /tmp, anche se non è stato rimosso dopo il riavvio. Lo stesso problema rimane, ma almeno è un po 'fuori mano.
anapsix

0

Prova ad aprire quella directory da Windows, potrebbe esserci qualcosa non mostrato in Mac OS. Ho avuto un problema simile dopo una serie di operazioni di copia tra Mac e Win PC: la directory era vuota anche nel terminale ma su Windows ho trovato un file Windows nascosto, quindi ho rimosso con successo la directory da lì.


0

Nel terminal:

  1. invio sudo su (il prompt della riga di comando dovrebbe passare a qualcosa di simile sh-3.2#.)
  2. vai alla cartella principale di quella che desideri eliminare
  3. accedere rm -rf TheDirectoryYouWantToDelete
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.