Mi stavo solo chiedendo come un sistema Windows gestisca i collegamenti simbolici. La mia ipotesi migliore è che non li riconoscerà, ma non sono del tutto sicuro.
Inoltre, cosa fanno i Mac di fronte a uno?
Mi stavo solo chiedendo come un sistema Windows gestisca i collegamenti simbolici. La mia ipotesi migliore è che non li riconoscerà, ma non sono del tutto sicuro.
Inoltre, cosa fanno i Mac di fronte a uno?
Risposte:
Dipende dalla versione di Windows e dalla configurazione del lato server quando parliamo di dischi non locali.
Da Windows Vista, Windows ha un'idea dei collegamenti simbolici, ma la semantica differisce. Ma il problema più importante qui dovrebbe essere i nomi dei percorsi, che seguono una sintassi diversa. Per cominciare: albero di directory a radice singola sul lato unixoid e diverse lettere di unità come root sul lato Windows.
Sul lato unixoid i symlink sono semplicemente file di testo con un flag speciale. Sul lato Windows, il meccanismo sottostante è chiamato punto di analisi. Questo dice al gestore oggetti di passarlo a particolari filtri registrati (la meta-data per questo è memorizzata nei punti di analisi). Windows 2000 ha già introdotto un tipo di punti di analisi noti come punti di giunzione (approssimativamente, ma non del tutto, collegamenti simbolici di directory). Con Vista hanno introdotto collegamenti simbolici a file e directory, anche su unità remote. E i collegamenti simbolici su unità remote sono anche supportati in una certa misura.
Il punto principale è se il driver del file system, se eseguito localmente, farebbe qualsiasi aggiustamento ai percorsi che Windows vede. In tal caso, funzionerebbe per determinati collegamenti simbolici locali / relativi. Per percorsi assoluti come obiettivi, le cose diventeranno difficili e impossibili da dedurre cosa si intende. Lo stesso vale per i collegamenti remoti symlink (a "condivisioni di rete").
Per quanto riguarda il lato Mac, non ne ho idea e potrebbe avere senso come una domanda separata. Ma finché il lato server trasmette l'informazione che si tratta di un collegamento simbolico, non vedo problemi, dal momento che entrambi seguono la semantica SUS (a differenza di Windows).
Considera i punti di montaggio laterali di Linux:
/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var
E ora considera un link simbolico che /home/paul/fstab
punta a /etc/fstab
. Si trovano su due diversi volumi che Windows - se in grado di vederli attraverso un driver del file system (che funziona!) - non può dire di appartenere al modo in /etc/fstab
cui lo descrive. Quindi il collegamento, che Windows vedrebbe sotto una cartella \paul\fstab
, anche se tradotto, indicherebbe \etc\fstab
, che non esiste /dev/sda2
. E se quel link simbolico indicasse il percorso relativo le ../../etc/fstab
cose non cambierebbero affatto.
L'essenza: quindi mentre è concepibile che tu possa farlo funzionare per alcuni casi angolari, il fatto che la semantica e la sintassi differiscano su entrambi i lati della recinzione rende improbabile che troverai un metodo pratico e generico che funzioni.
ntfs
supporta i punti di mount (se non ti piacciono tutte quelle lettere).
La risposta di 0xC0000022L è completa per il lato Windows delle cose. Il Mac è in grado di riconoscere i symlink di Linux; tuttavia Linux non è in grado di riconoscere gli alias creati nel Finder del Mac (i collegamenti simbolici creati usando ln -s funzionano correttamente).
.lnk
file).