Qual'è la differenza tra unlink e rm?


Risposte:


68

Entrambi sono un wrapper per la stessa funzione fondamentale che è una unlink()chiamata di sistema.

Per soppesare le differenze tra le utenze utente.

rm(1):

  • Più opzioni.
  • Più feedback.
  • Controllo della sanità mentale.
  • Un po 'più lento per le chiamate singole a causa di quanto sopra.
  • Può essere chiamato con più argomenti contemporaneamente.

unlink(1):

  • Meno controllo della sanità mentale.
  • Impossibile eliminare le directory.
  • Impossibile ricorrere.
  • Può accettare solo un argomento alla volta.
  • Marginalmente più snella per le chiamate singole grazie alla sua semplicità.
  • Più lento rispetto a dare rm(1)più argomenti.

Puoi dimostrare la differenza con:

$ touch $(seq 1 100)
$ unlink $(seq 1 100)
unlink: extra operand `2'

$ touch $(seq 1 100)
$ time rm $(seq 1 100)

real    0m0.048s
user    0m0.004s
sys     0m0.008s

$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do rm $i; done

real    0m0.207s
user    0m0.044s
sys     0m0.112s

$ touch $(seq 1 100)
$ time for i in $(seq 1 100); do unlink $i; done

real    0m0.167s
user    0m0.048s
sys     0m0.120s

Se tuttavia stiamo parlando di una chiamata semplice alla unlink(2)funzione di sistema , che ora mi rendo conto probabilmente non è ciò che stai spiegando.

È possibile eseguire un sistema unlink()su directory e file allo stesso modo. Ma se la directory è un genitore di altre directory e file, il collegamento a quel genitore verrebbe rimosso, ma i figli rimarrebbero penzoloni. Che è meno che ideale.

Modificare:

Spiacenti, ho chiarito la differenza tra unlink(1)e unlink(2). La semantica continuerà a differire tra le piattaforme.


Ciò significa che nei filesystem unix la rimozione di una directory e ricorsivamente tutti i file in essa contenuti saranno sempre operazioni proporzionali al numero di file / directory che contiene? Quando succede quando scollego una directory che è genitore di altre directory / file? Non viene mai spazzato via e ho perso questo spazio per sempre?
Marcin,

6
È tecnicamente possibile lasciare directory / file orfani sulla maggior parte, se non su tutti i file system. Risolvere questo problema in genere significa eseguire uno strumento di riparazione del file system. Su Unix / Linux questi strumenti sono noti come 'fsck' e alcune varianti specifiche per diversi file system. Se recuperano qualcosa, normalmente lo lasceranno in una directory chiamata 'lost + found'
ConcernedOfTunbridgeWells

1
Corretta. rm ricadrà dal fondo dell'albero in alto. È possibile dimostrare come con: mkdir -p 1/2/3; touch 1/one 1/2/two 1/2/3/three; rm -ri 1. Se hai scollegato la directory principale, lo spazio consumato dai figli dovrebbe essere perso fino a quando fsck non trova la discrepanza.
Dan Carley,

1
Di cosa stai parlando? $ mkdir -p 1/2/3 $ unlink 1 unlink: impossibile scollegare `1 ': una directory Gli utenti che causano perdite di" memoria "richiedono fsck? Improbabile!
Thomas,

1
Sia la manpage di Linux che quella di FreeBSD dichiarano esplicitamente che fallirà quando si tenta di eseguire unlink () su una directory.
Thomas,

8

A livello di specifica POSIX, ciò che fa rm è specificato molto più strettamente di ciò che fa unlink .

La portabilità del risultato sembra probabilmente migliore usando rm, se lo script deve essere eseguito su tutti i sistemi operativi.


4

La parte lenta della rimozione è il codice del file system e roba del disco, non la preparazione dello spazio utente della chiamata di sistema unlink ().

Vale a dire: se la differenza di velocità è importante, non dovresti archiviare i dati nel file system.

unlink è solo una "luce" rm. rm ha più funzioni ma fanno la stessa cosa.

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.