132 votes

Pouvez-vous changer le point sur un lien symbolique après sa création?

N'importe quel système d'exploitation fournissent un mécanisme (système d'appel - pas de programme en ligne de commande) pour modifier le chemin d'accès référencé par un lien symbolique (symlink) - autrement que par la séparation de l'ancien et d'en créer un nouveau?

La norme POSIX ne le fait pas. Solaris 10 ne fonctionne pas. MacOS X 10.5 (Leopard) ne fonctionne pas.

Est-il quelque chose qui le fasse?

(Je m'attends à ce que la réponse est "Non".)


Depuis de prouver un négatif est dur, nous allons réorganiser la question.

Si vous savez que certains (Unix-like) système d'exploitation n'est pas indiquée n'a pas de système d'appel pour la réécriture de la valeur d'un lien symbolique (la chaîne de caractères retournée par readlink()) sans enlever l'ancien lien symbolique et en créer un nouveau, s'il vous plaît ajouter le - ou les - dans une réponse. Car cela signifie qu'il ne sera probablement pas un seul "acceptable" réponse, je suis de la conversion au Wiki de la Communauté.

173voto

Taai Points 316

Oui, vous pouvez!

 $ ln -sfn source_file_or_directory_name softlink_name
 

112voto

Pascal Thivent Points 295221

Autant que je sache, non, vous ne pouvez pas. Vous devez le supprimer et de le recréer. En fait, vous pouvez remplacer un lien symbolique et donc de mettre à jour le chemin d'accès référencé par:

$ ln -s .bashrc test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc
$ ln -s .profil test
ln: création d'un lien symbolique `test': le Fichier existe
$ ln -s -f .profil test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profil

EDIT: Comme l'OP a souligné dans un commentaire, à l'aide de l' --force option, ln effectuer un appel système pour unlink() avant symlink(). Ci-dessous, la sortie de l' strace sur ma machine sous linux, la preuve:

$ strace -o /tmp/output.txt ln -s -f .bash_aliases test
$ grep -C3 ^dissocier /tmp/output.txt 
lstat64("test", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
un lien symbolique(".bash_aliases", "test") = -1 EEXIST (Fichier existe)
unlink("test") = 0
un lien symbolique(".bash_aliases", "test") = 0
close(0) = 0
fermeture(1) = 0

Donc je suppose que la réponse est "non".

15voto

mark4o Points 20472

Il n'est pas nécessaire explicitement dissocier l'ancien lien symbolique. Vous pouvez faire ceci:

ln -s newtarget temp
mv temp mylink

(ou utiliser l'équivalent lien symbolique et renommer des appels). C'est mieux que d'être explicitement la dissociation parce que renommer est atomique, de sorte que vous pouvez être assuré que le lien pointe toujours vers l'ancien ou le nouveau de la cible. Cependant ce ne sera pas la réutilisation de l'original de l'inode.

Sur certains systèmes de fichiers, la cible du lien symbolique est stocké dans l'inode lui-même (à la place de la liste de blocage) si il est assez court; ce qui est déterminé au moment où elle est créée.

Quant à l'affirmation que le propriétaire et le groupe ne sont pas significatifs, un lien symbolique(7) sur Linux dit qu'il y a un cas où il est important:

Le propriétaire et le groupe d'un lien symbolique peut être modifié à l'aide de lchown(2). La seule fois que la propriété d'un lien symbolique questions est lorsque le lien est supprimé ou renommé dans un répertoire qui porte le collant ensemble de bits (voir stat(2)).

Le dernier accès et l'horodatage de la dernière modification d'un lien symbolique peut être modifié à l'aide de utimensat(2) ou lutimes(3).

Sur Linux, les autorisations d'un lien symbolique n'est pas utilisé dans toutes les opérations; les autorisations sont toujours 0777 (lecture, écriture et exécution pour tous les utilisateurs les catégories), et ne peut pas être changé.

2voto

Markus Bucher Points 11

Juste un avertissement aux bonnes réponses ci-dessus:

L'utilisation de la méthode -f / --force présente le risque de perdre le fichier si vous mélangez la source et la cible:

 mbucher@server2:~/test$ ls -la
total 11448
drwxr-xr-x  2 mbucher www-data    4096 May 25 15:27 .
drwxr-xr-x 18 mbucher www-data    4096 May 25 15:13 ..
-rw-r--r--  1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
-rw-r--r--  1 mbucher www-data 7582480 May 25 15:27 otherdata.tar.gz
lrwxrwxrwx  1 mbucher www-data      11 May 25 15:26 thesymlink -> data.tar.gz
mbucher@server2:~/test$ 
mbucher@server2:~/test$ ln -s -f thesymlink otherdata.tar.gz 
mbucher@server2:~/test$ 
mbucher@server2:~/test$ ls -la
total 4028
drwxr-xr-x  2 mbucher www-data    4096 May 25 15:28 .
drwxr-xr-x 18 mbucher www-data    4096 May 25 15:13 ..
-rw-r--r--  1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
lrwxrwxrwx  1 mbucher www-data      10 May 25 15:28 otherdata.tar.gz -> thesymlink
lrwxrwxrwx  1 mbucher www-data      11 May 25 15:26 thesymlink -> data.tar.gz
 

Bien sûr, cela est prévu, mais des erreurs surviennent généralement. Donc, supprimer et reconstruire le lien symbolique est un peu plus de travail mais aussi un peu plus économe:

 mbucher@server2:~/test$ rm thesymlink && ln -s thesymlink otherdata.tar.gz 
ln: creating symbolic link `otherdata.tar.gz': File exists
 

qui au moins garde mon dossier.

1voto

matt b Points 73770

Ne pas le dissocier et créer le nouveau ne ferait-il pas la même chose au final?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X