Perché il mio link simbolico non funziona?

Sto cercando di capire meglio i collegamenti simbolici ... e non ho molta fortuna. Questo è l'output della mia shell reale con nome utente / host modificato:

username@host:~$ mkdir actual
username@host:~$ mkdir proper
username@host:~$ touch actual/file-1.txt
username@host:~$ echo "file 1" > actual/file-1.txt
username@host:~$ touch actual/file-2.txt
username@host:~$ echo "file 2" > actual/file-2.txt
username@host:~$ ln -s actual/file-1.txt actual/file-2.txt proper
username@host:~$ # Now, try to use the files through their links
username@host:~$ cat proper/file-1.txt
cat: proper/file-1.txt: No such file or directory
username@host:~$ cat proper/file-2.txt
cat: proper/file-2.txt: No such file or directory
username@host:~$ # Check that actual files do in fact exist
username@host:~$ cat actual/file-1.txt
file 1
username@host:~$ cat actual/file-2.txt
file 2
username@host:~$ # Remove the links and go home :(
username@host:~$ rm proper/file-1.txt
username@host:~$ rm proper/file-2.txt

Ho pensato che un collegamento simbolico doveva funzionare in modo trasparente, nel senso che si poteva operare sul file a cui punta come se si stesse accedendo direttamente al file (tranne ovviamente nel caso in rmcui ovviamente il link è semplicemente rimosso ).

I collegamenti simbolici tendono ad apprezzare percorsi completi o relativi al collegamento, altrimenti possono spesso cercare file-1.txtlocalmente (stranamente).

Naviga verso propered esegui ls -le puoi vedere che il link simbolico sta cercando actual/file-1.txt, quando dovrebbe essere ../actual/file-1.txt.

Quindi hai due opzioni:

1. Dai il percorso completo

   ln -s ~/actual/file-1.txt ~/actual/file-2.txt ~/proper

2. Passare alla cartella in cui si desidera inserire il collegamento e collegarsi da lì

   cd proper
   ln -s ../actual/file-1.txt ../actual/file-2.txt ./

Modifica : un suggerimento per salvare la digitazione.

Potresti semplicemente fare ln -s ~/actual/file-{1,2}.txt ~/proper

Gli elementi tra parentesi graffe vengono sostituiti e posizionati uno dopo l'altro, creando il comando

ln -s ~/actual/file-1.txt ~/actual/file-2.txt ~/proper

Il problema è l'uso di percorsi relativi. Se si specifica la creazione del collegamento con il percorso esplicito completo, funziona.

$ ln -s ~ / actual / file1.txt ~ / actual / file2.txt ~ / proper /

$ cat proper / file1.txt

file 1

$

Il tuo esempio crea collegamenti in properquella ricerca di una sottodirectory denominata effettiva nella directory corrente, anziché il tuo genitore di entrambi.

I collegamenti simbolici possono essere complicati. In sostanza, un collegamento simbolico è un file che contiene un nome file / percorso per un altro file (e che è contrassegnato per un trattamento speciale). Se il percorso nel file di collegamento inizia con ' /', viene trattato come un percorso assoluto e le cose sono abbastanza semplici. Se non inizia con una barra, viene trattato come un percorso relativo - relativo alla directory in cui si trova il collegamento. (Questo è vero indipendentemente dal fatto che il nome contenga o meno delle barre.) Quindi, hai creato proper/file–1.txtun collegamento a " actual/file–1.txt" e, quando hai provato ad accedervi, il sistema ha provato ad accedere proper/actual/file–1.txt. Avresti dovuto dire

ln –s  ../actual/file–1.txt  ../actual/file–2.txt  proper

A proposito, non avevi bisogno dei touchcomandi.  echo "file 1" > actual/file–1.txtè sufficiente creare actual/file–1.txt.

Un problema correlato, e potrebbe essere ovvio per molti, ma mi ha sconcertato per alcuni minuti: se stai creando un link simbolico all'interno di una directory che è esso stesso link simbolico, o c'è un link simbolico nel percorso della directory di lavoro corrente, potresti riscontrare problemi con i collegamenti simbolici non funzionanti.

Utilizzare cd ..e ls -lpiù volte per vedere se le directory principali sono esse stesse collegate simbolicamente.

Se è necessario creare un collegamento simbolico, cdalla directory di destinazione originale e creare lì nuovi collegamenti simbolici, i percorsi relativi sono accurati.

O, per dirla in altro modo: il percorso relativo va dall'origine alla destinazione. Se l'origine viene successivamente collegata a un link simbolico, va bene. Ma potresti riscontrare problemi nell'impostare un nuovo link_name Origin all'interno di una directory che è in qualche modo link simbolica.

Quando provi a creare un collegamento a un file che non esiste (o hai indicato il percorso in modo errato) ln -s non genera un errore. Crea un collegamento ma quando si tenta 'cat' su quel collegamento si dice che non è stato trovato alcun file. Anche quando puoi vederlo usando ls. In questi casi, controlla sempre il percorso del tuo file.

ubuntu@ip-172-31-80-155:~/lab5$ ln -s etc/ufw/ufw.conf link1
ubuntu@ip-172-31-80-155:~/lab5$ ls -al
total 5360
drwxrwxr-x 2 ubuntu ubuntu    4096 Mar  9 18:56 .
drwxr-xr-x 7 ubuntu ubuntu    4096 Mar  9 18:42 ..
-rwxr--r-- 1 ubuntu ubuntu 5478400 Mar  9 18:32 backup.tar
lrwxrwxrwx 1 ubuntu ubuntu      16 Mar  9 18:56 link1 -> etc/ufw/ufw.conf
ubuntu@ip-172-31-80-155:~/lab5$ cat link1
cat: link1: No such file or directory

Perché il file etc / ufw / ufw.conf non esiste. Il percorso corretto è /etc/ufw/ufw.conf

ubuntu@ip-172-31-80-155:~/lab5$ ln -s /etc/ufw/ufw.conf link2
ubuntu@ip-172-31-80-155:~/lab5$ ls -l
total 5352
-rwxr--r-- 1 ubuntu ubuntu 5478400 Mar  9 18:32 backup.tar
lrwxrwxrwx 1 ubuntu ubuntu      16 Mar  9 18:56 link1 -> etc/ufw/ufw.conf
lrwxrwxrwx 1 ubuntu ubuntu      17 Mar  9 19:00 link2 -> /etc/ufw/ufw.conf
ubuntu@ip-172-31-80-155:~/lab5$ cat link2
# /etc/ufw/ufw.conf
#

# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=no

# Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.
# See 'man ufw' for details.
LOGLEVEL=low