Quelle est la commande Unix pour créer un lien vers un répertoire dans OS X?

Je suis d’accord que les dossiers / répertoires de liaison peuvent causer des problèmes s’ils ne font pas attention, mais ils ont un avantage certain – Time Machine est un exemple parfait. Sans eux, cela ne serait tout simplement pas pratique, car la duplication des versions redondantes des fichiers consumrait très rapidement même les plus gros des disques.

Snow Leopard peut créer des liens vers des répertoires en respectant les six règles d’Amit Singh:

1. Le système de fichiers doit être journalisé HFS +.
2. Les répertoires parents de la source et de la destination doivent être différents.
3. Le parent de la source ne doit pas être le répertoire racine.
4. La destination ne doit pas être dans le répertoire racine.
5. La destination ne doit pas être un descendant de la source.
6. La destination ne doit avoir aucun ancêtre qui soit un lien de répertoire dur.

Il n’est donc pas correct que Snow Leopard ait perdu la possibilité de créer des liens vers des dossiers.

Je viens de vérifier que link / unlink fonctionne sur Snow Leopard – tant que vous suivez les six règles. Je l’ai juste essayé et cela fonctionne bien sur mon système Snow Leopard 10.6.6 – je l’ai essayé sur le volume de démarrage et sur un volume externe USB distinct et cela a bien fonctionné dans les deux cas.

Voici le programme “hunlink.c”:

#include  #include  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 

Donc, soyez prudent si vous l’essayez – n’oubliez pas de suivre les règles et utilisez hlink pour créer ces liens physiques et utilisez hunlink pour supprimer le lien physique par la suite. Et n’oubliez pas de documenter ce que vous avez fait pour plus tard ou pour quelqu’un d’autre qui pourrait avoir besoin de le savoir.

Un autre “gotcha” que je viens d’apprendre sur ces “liens durs” aux dossiers. Lorsque vous les créez, il se passe beaucoup de choses “derrière le rideau” de Mac OS X. Un problème vraiment important est que le dossier sur lequel vous créez le lien est vraiment déplacé vers un dossier super-caché appelé /.HFS+. Données du répertoire privé% 000d / dir_xxx où xxx est le numéro d’inode du “dossier_source” – rappelez-vous que le format de la commande est

 hlink source_folder target_folder 

Donc, pour cette raison, vous devez faire attention à ne pas avoir de fichiers ouverts dans le “dossier_source” car si vous le faites, ils ont juste été déplacés dans le dossier super-magique et vous aurez probablement un problème si vous essayez d’enregistrer les modifications. à ces fichiers qui étaient ouverts dans le “dossier_source”. Cela m’est arrivé plusieurs fois jusqu’à ce que je comprenne ce qui se passait et que la solution est assez simple. J’ai remarqué que vous ne pouviez plus faire de commande “ls -la” sans avoir des erreurs amusantes pour tous les dossiers / répertoires qui se trouvaient dans le répertoire “source_folder”, mais vous pouviez faire une commande “ls” et tout semblait correct.

Si vous exécutez “Verify disk” dans le programme “Disk Utility”, vous remarquerez qu’il se plaint probablement et donne un “bitmap de volume nécessitant une réparation mineure pour les blocs orphelins”, ce qui est arrivé avec la création du dossier super-magique. le mouvement du “dossier_source” à elle.

Si vous vous trouvez dans cette situation avec des “blocs orphelins”, sauvegardez d’abord les fichiers modifiés dans un autre emplacement temporaire ne figurant pas dans le volume contenant l’arborescence “source_folder”, puis utilisez “Utilitaire de disque” pour démonter et remonter le volume contenant le “dossier_source” ou redémarrez l’ordinateur. Ensuite, copiez les fichiers que vous avez enregistrés dans les emplacements temporaires vers leur emplacement d’origine et vous devriez être de retour en activité. C’est ce qui a fonctionné pour moi, donc ne peut pas garantir que cela fonctionnera pour vous aussi. Donc, il serait peut-être judicieux d’essayer ceci sur un volume sur lequel vous avez une bonne sauvegarde, au cas où.

Il semble tellement étrange que tous ces frais généraux surviennent simplement pour la simple tâche de créer un lien physique vers un dossier. Est-ce que quelqu’un a une idée de la raison pour laquelle Mac OS X fait tous ses efforts pour créer ce lien vers des dossiers? Cela a-t-il quelque chose à voir avec le fait qu’il s’agit d’un système de fichiers “journalisé”?

J’ai découvert les informations sur l’emplacement super-magique et super-caché en lisant les explications d’Amit Singh sur son utilitaire “hfsdebug”. Si vous voulez plus de détails, consultez son site Web à l’utilitaire hfsdebug d’Amit Singh . C’est un logiciel très intéressant qui vous donnera beaucoup de détails sur les systèmes de fichiers HFS +. C’est gratuit et je vous encourage à le télécharger et à l’essayer. Il n’est plus pris en charge, mais il fonctionne toujours sur Snow Leopard et Leopard, essentiellement tout système compatible HFS +. Vous ne pouvez pas vraiment faire de mal avec cela car il s’agit d’un outil “en lecture seule” – il est donc génial d’utiliser certains détails du système de fichiers.

Un autre problème à propos de ces “liens matériels vers les dossiers” – une fois que vous en créez un et que le dossier super-secret-caché super-magique est créé, il est là pour de bon. Même si vous dissociez le dossier à l’origine de sa création, ce dossier magique rest intact. Je ne sais pas pourquoi, mais c’est définitivement le cas. Vous pouvez utiliser “hfsdebug” pour le découvrir si vous souhaitez l’essayer. Vous pouvez également utiliser “hfsdebug” pour savoir combien de ces “liens matériels vers des dossiers” existent sur un lecteur. Pour ces détails, reportez-vous à l’article d’Amit sur l’utilitaire “hfsdebug”.

Il a également un autre utilitaire plus récent qui est pris en charge, mais les coûts. Il s’appelle fileXray et coûte 79 dollars pour une personne sur un nombre illimité d’ordinateurs du même foyer pour une licence personnelle de type non professionnel. Il contient un guide de l’utilisateur de 173 pages que vous pouvez télécharger pour voir ce qu’il peut faire avant de l’acheter. Malheureusement, il n’ya pas de version d’essai, alors lisez le manuel et consultez le site Web pour plus de détails et voir si cela peut vous aider à sortir d’un bourrage. Apprenez tous les détails à ce sujet sur leur site Web – voir le site Web fileXray pour plus d’informations.

Vous devez être conscient de quelques problèmes lorsque vous utilisez ces liens vers des dossiers. Si le volume sur lequel ils sont créés est monté sur un client distant, des problèmes importants peuvent survenir, selon leur mode de assembly. Si vous utilisez AFP pour monter le volume sur un client distant, il y a de gros problèmes car tous les dossiers qui ont un lien physique ou qui en ont déjà été supprimés ne pourront pas être utilisés comme tous les dossiers de niveau inférieur ( mais pas les fichiers) seront inaccessibles depuis le Finder ou une fenêtre Terminal. Si vous essayez de faire une simple commande “ls -lR”, cela échouera et vous recevrez des messages d’erreur “ls: xxx: No such file or directory” pour tous les dossiers de niveau inférieur. Si vous utilisez une fenêtre du Finder pour parcourir l’arborescence du volume distant, les dossiers qui se trouvent dans le dossier contenant un lien vers celui-ci disparaîtront tout simplement sans erreur lorsque vous cliquerez sur le nom du dossier.

Ces problèmes ne semblent pas se produire (sauf pour le message d’erreur) si vous utilisez NFS pour monter le client distant (et en supposant que vous avez un serveur NFS sur le système ayant le volume en tant que système de fichiers HFS + local). Les détails sur l’utilisation de NFS pour monter des volumes ne sont pas fournis ici. J’ai utilisé un bon programme du Dr. Marcel Bresink appelé “NFS Manager” pour aider avec les assemblys NFS sur le serveur et le client. Vous pouvez l’obtenir de son site Web – il suffit de rechercher “Bresink NFS Manager” dans votre moteur de recherche préféré, mais il a une version d’essai gratuite pour que vous puissiez essayer avant d’acheter. Ce n’est pas une grosse affaire si vous voulez apprendre à faire les assemblys NFS, mais le “NFS Manager” facilite la configuration et le réglage de tous les parameters pour l’optimiser. Il dispose de plusieurs autres utilitaires Mac OS X à des prix très raisonnables – l’un appelé “Hardware Monitor” qui vous permet de surveiller et de représenter graphiquement toutes sortes de choses comme la consommation élecsortingque, la température du processeur, la vitesse des ventilateurs et beaucoup d’autres variables. les systèmes Mac locaux et distants sur de longues périodes (de quelques minutes à quelques jours). Cela vaut la peine de vérifier si vous êtes dans des utilitaires pratiques.

Une chose que j’ai remarquée, c’est que les transferts de fichiers NFS étaient environ 20% plus lents que de les faire via AFP, mais votre «kilométrage peut varier», donc pas de garantie dans un sens ou dans l’autre, payer 20% de performance par rapport à ne rien faire du tout.

Apple est conscient des problèmes liés aux liens durs et aux systèmes de fichiers AFP distants, et les qualifie de “limitation d’implication” du client AFP – je préfère appeler cela ce qu’il me semble être vraiment – UN BUG !!! J’espère seulement que la prochaine version de Mac OS X résoudra le problème, car j’apprécie vraiment la possibilité d’utiliser des liens physiques vers des dossiers lorsque cela est logique.

Ces notes sont mon opinion personnelle et je ne donne aucune garantie quant à leur exactitude, alors utilisez-les à vos risques et périls. Ayez une bonne sauvegarde avant de jouer avec ces “liens matériels vers des dossiers” au cas où quelque chose d’imprévu se produirait. Mais j’espère que vous vous amuserez si vous décidez de vous pencher un peu plus sur cet aspect intéressant de Mac OS X.

Vous ne pouvez pas le faire directement dans BASH alors. Cependant … J’ai trouvé un article ici qui explique comment le faire indirectement: http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/index.html en compilant un petit programme C simple:

 #include  #include  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; } 

… et construire dans Terminal.app avec:

 $ gcc -o hlink hlink.c -Wall 

Balivernes. Sur 10.5, il vous indique dans la page de manuel pour ln :

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

Donc oui:

  sudo ln -d existing_dir new_hard_link 

Donnez-lui votre mot de passe, et vous ne l’avez pas encore fait . Vous ne l’avez pas documenté, n’est-ce pas? Vous devez documenter les répertoires liés en dur; même si c’est une machine mono-utilisateur.

La suppression est une autre histoire: si vous le faites de la manière habituelle pour supprimer des répertoires, vous supprimerez le contenu. Vous devez donc “dissocier” le répertoire:

  unlink new_hard_link 

Là. J’espère que vous ne détruisez pas votre système de fichiers!

Transférer ce formidable outil qui résout parfaitement le problème, initialement posté par Sam :

Pour installer Hardlink, assurez-vous d’avoir installé homebrew , puis exécutez:

 brew install hardlink-osx 

Une fois installé, créez un lien dur avec:

 hln [source] [destination] 

J’ai aussi remarqué que la commande unlink ne fonctionne pas sur le léopard des neiges, alors j’ai ajouté une option pour dissocier:

 hln -u destination 

Le code est disponible sur Github pour ceux qui sont intéressés: https://github.com/selkhateeb/hardlink

Oui, il est supporté par le kernel et le système de fichiers, mais comme il n’est pas destiné à un usage général, il n’est pas exposé au shell.

Vous pourriez probablement déterminer les API utilisées par Time Machine et les envelopper dans un outil en ligne de commande, mais il serait préférable de prendre l’allusion et de bien vous diriger.

La version OSX de ln ne peut pas le faire, mais, comme mentionné dans l’autre réponse de rich , il est possible avec la version GNU de ln qui est disponible en homebrew sous la forme gln dans la formule de coreutils . man gln liste l’option -d avec l’avertissement spécifique à OSX fourni dans la réponse de rich . En d’autres termes, cela ne fonctionne pas dans tous les cas. Ce qui détermine exactement si cela fonctionne ou non ne semble être documenté nulle part.

Prérequirejs, installez coreutils :

  brew install coreutils 

Maintenant vous pouvez faire:

  sudo gln -d /original_folder /mirror_folder 

IMPORTANT : pour supprimer le lien gunlink vous devez utiliser gunlink :

  sudo gunlink /mirror_folder 

Utiliser rm ou Finder supprimera également le dossier d’origine.

FYI: La formule homebrew de coreutils fournit les versions compatibles GNU des outils Unix génériques. Utilisez la brew list coreutils pour voir la liste complète.

Mon cas était que j’ai découvert que sur une machine virtuelle Windows, je ne peux pas suivre les liens symboliques. (Je voulais tester certaines pages HTML dans Internet Explorer). Et ma structure de répertoires comportait des liens symboliques pour les dossiers CSS et images.

Ma solution de rechange pour résoudre le problème était une approche différente de celle des autres réponses. J’ai utilisé rsync pour créer une copie du dossier. Rsync peut résoudre les liens symboliques et copier les fichiers liés à la place.

Cela a résolu mon problème sans utiliser de liens durs vers des répertoires. Et c’est en fait une solution simple si vous travaillez uniquement sur un petit ensemble de fichiers.

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

La réponse courte est que vous ne pouvez pas. 🙂 (sauf éventuellement en tant que root, quand il serait plus exact de dire que vous ne devriez pas.)

Les Unix ne permettent qu’un nombre défini de liens vers des répertoires – “..” à partir de tous ses enfants et “.” de l’intérieur. Tout le rest est potentiellement une recette pour une arborescence de répertoires très confuse. C’est / était apparemment une décision de conception de Ken Thompson.

(Cela dit, apparemment, Time Machine d’Apple le fait :))

De l’article lié à, vous obtiendrez cette erreur si vous essayez de créer le lien dur dans le même répertoire que l’original. Vous devez le créer ailleurs.

Cela peut également être fait avec Perl intégré (à partir de Terminal) sans rien comstackr. Mon cas d’utilisation spécifique concerne Google Drive (qui ne prend pas en charge les liens symboliques). Les exemples ci-dessous reflètent donc le cas d’utilisation.

Pour lier votre dossier “Documents” à Google Drive afin qu’il soit synchronisé:

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

Pour supprimer le lien vers votre dossier “Documents” depuis Google Drive:

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

Vous avez besoin de “root” pour dissocier (voir perldoc “unlink”).

Une autre solution consiste à utiliser bindfs https://code.google.com/p/bindfs/ qui peut être installé via le port:

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

dans le cas où il n’y a pas de sous-dossier, vous pouvez essayer

Dans folder_path / * . * dossier-cible

cela a fonctionné pour moi sur OSX 10.9

Sous Linux, vous pouvez utiliser bind mount pour simuler des répertoires de liens durs. Pas sur OSX

 sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory sudo umount /else/dummy_but_existing_directory