Qual è il comando Unix per creare un collegamento fisico a una directory in OS X?

StackOverflow https://stackoverflow.com/questions/80875

Domanda

Come si crea un collegamento fisico (al contrario di un collegamento simbolico o di un alias Mac OS) in OS X che punta a una directory?Conosco già il comando "ln destinazione destinazione" ma funziona solo quando la destinazione è un file.So che Mac OS, a differenza di altri ambienti Unix, consente il collegamento fisico alle cartelle (questo viene utilizzato per Time Machine, ad esempio) ma non so come farlo da solo.

È stato utile?

Soluzione 2

Allora non puoi farlo direttamente in BASH.Tuttavia...Ho trovato un articolo qui che spiega come farlo indirettamente: http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/index.html compilando un semplice programma in C:

#include <unistd.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
   if (argc != 3) return 1;

   int ret = link(argv[1], argv[2]);

   if (ret != 0) perror("link");

   return ret;
}

...e crea Terminal.app con:

$ gcc -o hlink hlink.c -Wall

Altri suggerimenti

Sono d'accordo sul fatto che cartelle/directory con collegamento fisico possono causare problemi se non si fa attenzione, ma hanno un vantaggio molto preciso: Time Machine è un esempio perfetto.Senza di essi semplicemente non sarebbe pratico poiché la duplicazione di versioni ridondanti di file consumerebbe molto rapidamente anche il disco più grande.

Snow Leopard può creare collegamenti fisici alle directory purché si seguano le sei regole di Amit Singh:

  1. Il file system deve essere registrato su journal HFS+.
  2. Le directory principali dell'origine e della destinazione devono essere diverse.
  3. Il genitore dell'origine non deve essere la directory root.
  4. La destinazione non deve trovarsi nella directory principale.
  5. La destinazione non deve essere un discendente dell'origine.
  6. La destinazione non deve avere alcun antenato che sia un collegamento reale alla directory.

Quindi non è affatto corretto che Snow Leopard abbia perso la capacità di creare collegamenti duri alle cartelle.

Ho appena verificato che Link/Unlink lavora su Snow Leopard, purché tu segua le sei regole.L'ho appena provato e funziona bene sul mio sistema Snow Leopard 10.6.6: l'ho provato sul volume di avvio e su un volume USB esterno separato e ha funzionato bene in entrambi i casi.

Ecco il programma "hunlink.c":

#include <stdio.h>
#include <unistd.h>
int
main(int argc, char *argv[])
{
   if (argc != 2)
      return 1;
   int ret = unlink(argv[1]);
   if (ret != 0)
      perror("unlink");
   return ret;
}

gcc -o hunlink hunlink.c

Quindi, fai attenzione se lo provi: ricorda di seguire le regole e di utilizzare hlink per creare questi collegamenti fisici e utilizzare hunlink per rimuovere il collegamento reale in seguito.E non dimenticare di documentare ciò che hai fatto per dopo o per qualcun altro che potrebbe aver bisogno di saperlo.

Un altro "gotcha" che ho appena appreso su questi "collegamenti reali" alle cartelle.Quando li crei, succedono davvero molte cose "dietro le quinte" di Mac OS X.Un problema davvero importante è che la cartella a cui crei il collegamento viene realmente spostata in una magica cartella super nascosta chiamata /.HFS+ Private Directory Data%000d/dir_xxx dove xxx è il numero di inode della "cartella_origine" - ricorda il il formato del comando è 

hlink source_folder target_folder

Quindi, per questo motivo, devi stare attento a non avere alcun file aperto nella "cartella_origine" perché se lo fai, verranno semplicemente spostati nella cartella super magica e probabilmente avrai un problema se provi a salvare eventuali modifiche a quei file che erano aperti nella "cartella_origine".Questo mi è successo un paio di volte finché non ho capito cosa stava succedendo e la soluzione è piuttosto semplice.Ho notato che non potevi più eseguire un comando "ls -la" senza ottenere errori divertenti per tutte le cartelle/directory presenti nella "cartella_sorgente" originale ma potevi eseguire un comando "ls" e tutto sembrava a posto.

Se esegui "Verifica disco" nel programma "Utility Disco", noterai che probabilmente si lamenta e restituisce un messaggio "La bitmap del volume necessita di una piccola riparazione per i blocchi orfani" che è ciò che è appena successo con la creazione della cartella super magica e lo spostamento della "cartella_origine" ad esso.

Se ti trovi in ​​questa situazione con "blocchi orfani", salva prima i file modificati in qualche altra posizione temporanea non nel volume contenente l'albero "source_folder", quindi utilizza "Utility Disco" per smontare e rimontare il volume che contiene i "source_folder" o semplicemente riavviare il computer.Quindi copia i file salvati nelle posizioni temporanee nelle posizioni originali e dovresti tornare al lavoro.Questo è ciò che ha funzionato per me, quindi non posso garantire che funzionerà anche per te.Quindi potrebbe essere una buona idea provarlo su un volume di cui si dispone di un buon backup per ogni evenienza.

Sembra davvero strano che tutto questo sovraccarico si verifichi solo per il semplice compito di creare un collegamento fisico a una cartella.Qualcuno ha idea del motivo per cui Mac OS X fa tutto questo sforzo per creare questo collegamento fisico alle cartelle?Ha qualcosa a che fare con il fatto che si tratta di un file system "journaled"?

Ho scoperto le informazioni sulla posizione super magica e super nascosta leggendo la spiegazione di Amit Singh della sua utility "hfsdebug".Se vuoi maggiori dettagli consulta il suo sito web all'indirizzo L'utilità hfsdebug di Amit Singh.È un software molto interessante e ti fornirà molti dettagli sui file system HFS+.È gratuito e ti incoraggio a scaricarlo e provarlo.Non è più supportato ma funziona ancora sia su Snow Leopard che su Leopard, praticamente su qualsiasi sistema supportato da HFS+.Non puoi davvero fargli alcun danno dato che è uno strumento di "sola lettura", quindi è fantastico usarlo per osservare alcuni dettagli del filesystem.

Un altro problema relativo a questi "collegamenti fisici alle cartelle": una volta che ne crei uno e la cartella super magica e super segreta viene creata, è lì per sempre.Anche se scolleghi la cartella che ne ha causato la creazione, questa cartella magica rimane in circolazione.Non so perché, ma sicuramente lo fa.Puoi usare "hfsdebug" per scoprirlo se desideri provarlo.Puoi anche utilizzare "hfsdebug" per scoprire quanti di questi "collegamenti fisici alle cartelle" esistono su un'unità.Per questi dettagli fare riferimento all'articolo di Amit sull'utility "hfsdebug".

Ha anche un'altra utilità più recente supportata ma a pagamento.Si chiama fileXray e costa 79 dollari per una persona su un numero qualsiasi di computer nella stessa famiglia per una licenza di tipo personale e non aziendale.Ha un'ampia guida per l'utente di 173 pagine che puoi scaricare per vedere cosa può fare prima dell'acquisto.Sfortunatamente non esiste una versione di prova, quindi leggi il manuale e controlla il sito web per maggiori dettagli e vedere se può aiutarti a uscire da un ingorgo.Scopri tutti i dettagli al riguardo sul loro sito web - vedi sito web fileXray per maggiori informazioni.

Ci sono un paio di problemi di cui dovresti essere consapevole quando usi questi collegamenti fisici alle cartelle.Se il volume su cui vengono creati è montato su un client remoto, potrebbero verificarsi problemi significativi, a seconda di come vengono montati.Se si utilizza AFP per montare il volume su un client remoto, ci sono grossi problemi poiché qualsiasi cartella che attualmente ha un collegamento reale ad esso o che ne ha mai avuto uno ma successivamente rimossa, non potrà essere utilizzata come tutte le cartelle di livello inferiore ( ma non file) saranno inaccessibili sia dal Finder che da una finestra di Terminale.Se provi a eseguire un semplice comando "ls -lR", fallirà e ti darà "ls:xxx:Messaggi di errore "Nessun file o directory" per tutte le cartelle di livello inferiore.Se utilizzi una finestra del Finder per attraversare l'albero delle directory del volume remoto, le cartelle che si trovano nella cartella che aveva o ha un collegamento reale ad essa scompariranno semplicemente senza alcun errore quando fai clic per la prima volta sul nome della cartella.

Questi problemi non sembrano verificarsi (ad eccezione del messaggio di errore) se si utilizza NFS per montare il client remoto (e presupponendo che sul sistema sia presente un server NFS con il volume come file system HFS+ locale).I dettagli su come utilizzare NFS per montare i volumi non vengono forniti qui.Ho usato un bel programma del Dr.Marcel Bresink ha chiamato "NFS Manager" per aiutare con i montaggi NFS sul server e sul client.Puoi ottenerlo dal suo sito web: cerca semplicemente "Bresink NFS Manager" nel tuo motore di ricerca preferito, ma ha una versione di prova gratuita così puoi provare prima di acquistare.Non è un grosso problema se vuoi imparare come eseguire i montaggi NFS, ma "NFS Manager" rende abbastanza semplice impostare le cose e modificare tutte le diverse impostazioni per ottimizzare il tutto.Ha anche molte altre utilità per Mac OS X a prezzi molto ragionevoli: una chiamata "Hardware Monitor" che ti consente di monitorare e rappresentare graficamente tutti i tipi di cose come il consumo energetico, la temperatura della CPU, la velocità delle ventole e molte altre variabili per entrambi i sistemi Mac locali e remoti per periodi di tempo estesi (da minuti a giorni).Sicuramente vale la pena provarlo se ti piacciono le utilità utili.

Una cosa che ho notato è che i trasferimenti di file NFS erano circa il 20% più lenti rispetto a quelli eseguiti tramite AFP, ma il "chilometraggio può variare", quindi non ci sono garanzie in un modo o nell'altro, ma preferirei avere qualcosa che funzioni anche se ho pagare un calo delle prestazioni del 20% rispetto a non avere alcun lavoro.

Apple è consapevole dei problemi con gli hard link e i filesystem AFP remoti, e si riferisce a ciò come a una "limitazione di implementazione" del client AFP - preferisco chiamarlo come mi sembra realmente - UN BUG!!!Posso solo sperare che la prossima versione di Mac OS X risolva il problema, poiché mi piace molto avere la possibilità di utilizzare collegamenti fisici alle cartelle quando ha senso.

Queste note rappresentano la mia opinione personale e non fornisco alcuna garanzia sulla loro correttezza, quindi usale a tuo rischio e pericolo.Fai un buon backup prima di giocare con questi "collegamenti fisici alle cartelle" nel caso in cui accada qualcosa di imprevisto.Ma spero che ti divertirai se deciderai di approfondire questo aspetto interessante di Mac OS X.

Piffle.Nella versione 10.5, te lo dice nella pagina man for ln:

   -d, -F, --directory
          allow the superuser to attempt to hard link  directories  (note:
          will  probably  fail  due  to  system restrictions, even for the
          superuser)

Quindi sì:

    sudo  ln  -d  existing_dir  new_hard_link

Dategli la vostra password e non hai ancora finito.Non l'hai documentato, vero?Voi dovere documentare le directory con collegamenti fisici;anche se si tratta di una macchina con un solo utente.

L'eliminazione è una storia diversa:se procedi nel solito modo per eliminare le directory, eliminerai il contenuto.Quindi tu dovere "scollega" la directory:

    unlink  new_hard_link

Là.Spero che tu non rovini il tuo filesystem!

Pubblicazione incrociata questo fantastico strumento che risolve perfettamente il problema, originariamente pubblicato da Sam:

Per installare Hardlink, assicurati di averlo installato birra fatta in casa, quindi esegui:

brew install hardlink-osx

Una volta installato, crea un collegamento reale con:

hln [source] [destination]

L'ho notato anche io unlink il comando non funziona su Snow Leopard, quindi ho aggiunto un'opzione per scollegare:

hln -u destination

Il codice è disponibile su Github per coloro che sono interessati: https://github.com/selkhateeb/hardlink

Sì, è supportato dal kernel e dal filesystem, ma poiché non è destinato all'uso generale non è esposto alla shell.

Probabilmente potresti capire quali API utilizza Time Machine e inserirle in uno strumento a riga di comando, ma sarebbe meglio cogliere il suggerimento e stare alla larga.

La versione OSX di ln non posso farlo, ma, come menzionato nell'altra risposta di ricco, è possibile con la versione GNU di ln che è disponibile in birra fatta in casa COME gln come parte di coreutils formula. man gln elenca il -d opzione con l'avviso specifico per OSX fornito in riccoè la risposta.In altre parole, non funziona in tutti i casi.Ciò che determina esattamente se funziona o meno non sembra essere documentato da nessuna parte.

Come prerequisito, installare coreutils:

    brew install coreutils

Ora puoi fare:

    sudo gln -d /original_folder /mirror_folder

IMPORTANTE:Per rimuovere l'hard link you dovere utilizzo gunlink:

    sudo gunlink /mirror_folder

Utilizzando rm o il Finder eliminerà anche la cartella originale.

PER TUA INFORMAZIONE:IL coreutils La formula homebrew fornisce le versioni compatibili con GNU di strumenti Unix generici.Utilizzo brew list coreutils per vedere l'elenco completo.

Il mio caso è stato che ho scoperto che da una macchina virtuale Windows non posso seguire i collegamenti simbolici.(volevo testare alcune pagine HTML in Internet Explorer).E la mia struttura di directory aveva collegamenti simbolici per le cartelle CSS e immagini.

La mia soluzione alternativa per risolvere il problema era un approccio diverso rispetto a quello implicito nelle altre risposte.ero solito rsync per creare una copia della cartella.Rsync può risolvere i collegamenti simbolici e copiare invece i file collegati.

Questo ha risolto il mio problema senza utilizzare collegamenti reali alle directory.Ed è in realtà una soluzione semplice se stai lavorando solo su un piccolo set di file.

rsync -av --copy-dirlinks --delete ../htmlguide ~/src/

Dal 2018 non è più possibile.APFS (introdotto in MacOS High Sierra 10.13) non è compatibile con i collegamenti fisici alle directory.Vedere https://github.com/selkhateeb/hardlink/issues/31

La risposta breve è che non puoi.:) (tranne forse come root, quando sarebbe più accurato dire che non dovresti.)

Gli Unixs consentono solo un numero impostato di collegamenti alle directory - ".." all'interno di tutti i suoi figli e "". da dentro di sé.Qualsiasi altra cosa è potenzialmente una ricetta per un albero di directory molto confuso.Questa è/era apparentemente una decisione progettuale di Ken Thompson.

(Detto questo, a quanto pare Time Machine di Apple fa questo :))

Dall'articolo collegato, riceverai quell'errore se provi a creare il collegamento reale nella stessa directory dell'originale.Devi crearlo da qualche altra parte.

Questo può essere fatto anche con Perl integrato (dal Terminale) senza compilare nulla.Il mio caso d'uso specifico è per Google Drive (che non supporta i collegamenti simbolici), quindi gli esempi seguenti riflettono il caso d'uso.

Per collegare la cartella "Documenti" a Google Drive in modo che sia sincronizzata:

perl -e 'link "/Users/me/Documents", "/Users/me/Google Drive/Documents"'

Per rimuovere il collegamento alla cartella "Documenti" da Google Drive:

sudo perl -U -e 'unlink "/Users/me/Google Drive/Documents"'

Hai bisogno di "root" per scollegarti (vedi "unlink" perldoc).

Un'altra soluzione è usare bindfs https://code.google.com/p/bindfs/ che è installabile tramite porta:

sudo port install bindfs
sudo bindfs ~/source_dir ~/target_dir

nel caso in cui non sia presente una sottocartella, puoi provare

ln percorso_cartella/*.*cartella_destinazione

ha funzionato per me su OSX 10.9

In Linux è possibile utilizzare il bind mount per simulare le directory con collegamento reale.Non sono sicuro di OSX

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top