Qu'est-ce que la commande Unix pour créer un lien dur vers un répertoire sous OS X?
Comment créer un lien physique (par opposition à un lien symbolique ou un alias Mac OS) dans OS X qui pointe vers un répertoire? Je connais déjà la commande "ln target destination" mais cela ne fonctionne que lorsque la cible est un fichier. Je sais que Mac OS, contrairement à d'autres environnements Unix, autorise les liens physiques vers des dossiers (ceci est utilisé pour Time Machine, par exemple) mais je ne sais pas comment le faire moi-même.
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 by compiler un petit programme C simple:
#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;
}
... et intégrez Terminal.app avec:
$ gcc -o hlink hlink.c -Wall
Je suis d'accord que les dossiers/répertoires liés en dur peuvent causer des problèmes s'ils ne sont pas prudents, mais ils ont un avantage très net - Time Machine est un exemple parfait. Sans eux, cela ne serait tout simplement pas pratique car la duplication de versions redondantes de fichiers consommerait très rapidement même le plus grand des disques.
Snow Leopard peut créer des liens durs vers des répertoires tant que vous suivez les six règles d'Amit Singh:
- Le système de fichiers doit être journalisé HFS +.
- Les répertoires parents de la source et de la destination doivent être différents.
- Le parent de la source ne doit pas être le répertoire racine.
- La destination ne doit pas se trouver dans le répertoire racine.
- La destination ne doit pas être un descendant de la source.
- La destination ne doit avoir aucun ancêtre qui soit un lien dur d'annuaire.
Il n'est donc pas du tout correct que Snow Leopard ait perdu la possibilité de créer des liens durs vers des dossiers.
Je viens de vérifier que le lien/dissociation fonctionne sur Snow Leopard - tant que vous suivez les six règles. Je viens de l'essayer 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 séparé et cela a bien fonctionné dans les deux cas.
Voici le programme "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
Donc, soyez prudent si vous l'essayez - n'oubliez pas de suivre les règles et utilisez hlink pour créer ces liens durs et utilisez hunlink pour supprimer le lien dur par la suite. Et n'oubliez pas de documenter ce que vous avez fait 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" vers des dossiers. Lorsque vous les créez, il se passe vraiment beaucoup de choses "derrière le rideau" de Mac OS X. Un problème très important est que le dossier vers lequel vous créez le lien est vraiment déplacé vers un dossier super-magique super caché appelé /.HFS+ Données de 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 à cause de cela, vous devez faire attention à ne pas avoir de fichiers ouverts dans le "dossier_source" car si vous le faites, ils viennent d'être déplacés vers le dossier super-magique et vous aurez probablement un problème si vous essayez d'enregistrer les modifications aux fichiers qui étaient ouverts dans le "dossier_source". Cela m'est arrivé plusieurs fois jusqu'à ce que je me rende compte de ce qui se passait et la solution est assez simple. J'ai remarqué que vous ne pouviez plus exécuter une commande "ls -la" sans obtenir des erreurs amusantes pour tous les dossiers/répertoires qui se trouvaient dans le "dossier_source" d'origine, mais vous pouviez exécuter une commande "ls" et tout avait l'air bien.
Si vous exécutez "Vérifier le disque" dans le programme "Utilitaire de disque", 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 vient de se produire avec la création du dossier super-magique et le déplacement du "dossier_source" vers celui-ci.
Si vous vous trouvez dans cette situation avec des "blocs orphelins", enregistrez d'abord les fichiers modifiés dans un autre emplacement temporaire ne se trouvant pas dans le volume contenant l'arborescence "dossier_source", puis utilisez "Utilitaire de disque" pour démonter et remonter le volume qui contient le "dossier_source" ou redémarrez simplement l'ordinateur. Copiez ensuite les fichiers que vous avez enregistrés dans les emplacements temporaires vers leurs emplacements d'origine et vous devriez reprendre le travail. C'est ce qui a fonctionné pour moi, donc je ne peux pas garantir que cela fonctionnera aussi pour vous. Il peut donc être judicieux de l'essayer sur un volume dont vous disposez d'une bonne sauvegarde au cas où.
Cela semble tellement bizarre que tout ce surcoût se produit uniquement pour la simple tâche de créer un lien dur vers un dossier. Quelqu'un a-t-il une idée de la raison pour laquelle Mac OS X fait tous ces efforts pour cette création de lien dur 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 l'explication d'Amit Singh de son utilitaire "hfsdebug". Si vous voulez plus de détails, consultez son site Web à tilitaire 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 à la fois sur Snow Leopard et Leopard - essentiellement tout système pris en charge HFS +. Vous ne pouvez pas vraiment lui faire de mal car c'est un outil "en lecture seule" - donc c'est génial à utiliser pour regarder certains détails du système de fichiers.
Un autre problème à propos de ces "liens durs vers les dossiers" - une fois que vous en avez créé un et que le dossier super-magique super-secret-caché est créé, il est là pour de bon. Même si vous dissociez le dossier qui a provoqué sa création en premier lieu, ce dossier magique reste en place. Je ne sais pas pourquoi, mais c'est sûr. Vous pouvez utiliser "hfsdebug" pour le découvrir si vous souhaitez l'essayer. Vous pouvez également utiliser "hfsdebug" pour savoir combien de ces "liens durs 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 coûte. Il s'appelle fileXray et coûte 79 $ pour une personne sur n'importe quel nombre d'ordinateurs dans le même ménage pour une licence personnelle non commerciale. Il contient un guide de l'utilisateur complet de 173 pages que vous pouvez télécharger pour voir ce qu'il peut faire avant d'acheter. Malheureusement, il n'y a pas de version d'essai, alors lisez le manuel et consultez le site Web pour plus de détails pour voir si cela peut vous aider à sortir d'un bourrage. Apprenez tous les détails à ce sujet sur leur site Web - voir site Web fileXray pour plus d'informations.
Il y a quelques problèmes que vous devez savoir lorsque vous utilisez ces liens durs vers des dossiers. Si le volume sur lequel ils sont créés est monté sur un client distant, il peut y avoir des problèmes importants, selon la façon dont ils sont montés. Si vous utilisez AFP pour monter le volume sur un client distant, il y a de gros problèmes car tout dossier qui a actuellement un lien dur vers celui-ci ou en a déjà eu un mais supprimé plus tard, ne pourra pas être utilisé comme tous les dossiers de niveau inférieur ( mais pas les fichiers) sera inaccessible à partir du Finder ou d'une fenêtre de terminal. Si vous essayez d'exécuter une simple commande "ls -lR", elle échouera et vous donnera 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 de répertoires du volume distant, les dossiers qui se trouvent dans le dossier qui avait ou a un lien dur vers celui-ci disparaîtront simplement sans aucune erreur lorsque vous cliquez pour la première fois sur le nom du dossier.
Ces problèmes ne semblent pas se produire (à l'exception du message d'erreur) si vous utilisez NFS pour monter le client distant (et en supposant que vous disposiez d'un serveur NFS sur le système qui a 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 programme Nice du Dr Marcel Bresink appelé "NFS Manager" pour aider avec les montages NFS sur le serveur et le client. Vous pouvez l'obtenir à partir de son site Web - recherchez simplement "Bresink NFS Manager" dans votre moteur de recherche préféré, mais il a une version d'essai gratuite afin que vous puissiez essayer avant d'acheter. Ce n'est pas si grave si vous voulez apprendre à faire les montages NFS, mais le "NFS Manager" facilite la configuration et le réglage de tous les différents paramètres pour aider à l'optimiser. Il a également plusieurs autres utilitaires Mac OS X à un prix très raisonnable - celui appelé "Hardware Monitor" qui vous permet de surveiller et de représenter toutes sortes de choses comme la consommation d'énergie, la température du processeur, la vitesse des ventilateurs et de nombreuses autres variables pour les deux. les systèmes Mac locaux et distants sur de longues périodes (de quelques minutes à plusieurs jours). Il vaut vraiment la peine de vérifier si vous êtes dans des utilitaires pratiques.
Une chose que j'ai remarquée est que les transferts de fichiers NFS étaient environ 20% plus lents que ceux effectués via AFP, mais votre "kilométrage peut varier", donc aucune garantie dans un sens ou dans l'autre, mais je préférerais que quelque chose fonctionne même si j'ai de payer un coup de performance de 20% par rapport à ne rien avoir du tout.
Apple est conscient des problèmes avec les liens durs et les systèmes de fichiers AFP distants, et ils y font référence comme une "limitation d'implémentation" du client AFP - je préfère l'appeler ce qu'il me semble vraiment être - UN BUG !!! Je ne peux qu'espérer que la prochaine version de Mac OS X résoudra le problème, car j'aime vraiment avoir la possibilité d'utiliser des liens durs vers des dossiers quand cela a du sens.
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 durs vers les 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.
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 restrictions, even for the
superuser)
Donc oui:
Sudo ln -d existing_dir new_hard_link
Donnez-lui votre mot de passe et vous n'avez pas encore fini. Vous ne l'avez pas documenté, n'est-ce pas? Vous devez documenter les répertoires liés en dur; même s'il s'agit d'une machine mono-utilisateur.
La suppression est une autre histoire: si vous procédez comme d'habitude pour supprimer des répertoires, vous en supprimerez le contenu. Donc vous devez "dissocier" le répertoire:
unlink new_hard_link
Là. J'espère que vous ne détruisez pas votre système de fichiers!
Publication croisée cet excellent outil qui résout proprement le problème, initialement publié 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 également remarqué que la commande unlink ne fonctionne pas sur le léopard des neiges, j'ai donc 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 pris en charge par le noyau 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 quelles API Time Machine utilise et les encapsuler dans un outil en ligne de commande, mais il serait préférable de prendre l'indice et de bien diriger.
La version OSX de ln ne peut pas le faire, mais, comme mentionné dans l'autre réponse par rich , c'est possible avec la version GNU de ln qui est disponible dans homebrew comme gln dans le cadre de la formule coreutils . man gln répertorie les -d option 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érequis, installez coreutils:
brew install coreutils
Vous pouvez maintenant:
Sudo gln -d /original_folder /mirror_folder
[~ # ~] important [~ # ~] : Pour supprimer le lien dur, vous devez utilisez gunlink:
Sudo gunlink /mirror_folder
L'utilisation de rm ou du Finder supprimera également le dossier d'origine.
Pour info: la formule homebrew coreutils fournit les versions compatibles GNU des outils Unix génériques. Utilisation brew list coreutils pour voir la liste complète.
À partir de 2018, ce n'est plus possible. APFS (introduit dans MacOS High Sierra 10.13) n'est pas compatible avec les liens physiques de répertoire. Voir https://github.com/selkhateeb/hardlink/issues/31
Mon cas était que j'ai découvert qu'à partir d'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 avait des liens symboliques pour les dossiers CSS et images.
Ma solution de contournement pour résoudre le problème était une approche différente de celle des autres réponses impliquées. 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 facile 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 précis de dire que vous ne devriez pas.)
Les Unix n'autorisent qu'un nombre défini de liens vers des répertoires - ".." dans tous ses enfants et "." de l'intérieur de lui-même. Tout le reste est potentiellement une recette pour une arborescence de répertoires très confuse. Il s'agit/était apparemment une décision de conception de Ken Thompson.
(Cela dit, apparemment, Time Machine d'Apple le fait :))
Sous Linux, vous pouvez utiliser bind mount pour simuler des répertoires de liaison matériels. Pas sûr d'OSX
Sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
Sudo umount /else/dummy_but_existing_directory
Cela peut également être fait avec Perl intégré (depuis Terminal) sans rien compiler. Mon cas d'utilisation spécifique est pour Google Drive (qui ne prend pas en charge les liens symboliques), les exemples ci-dessous reflètent donc le cas d'utilisation.
Pour associer 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" de Google Drive:
Sudo Perl -U -e 'unlink "/Users/me/Google Drive/Documents"'
Vous avez besoin de "root" pour dissocier (voir "dissocier" perldoc).
À partir 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.
Une autre solution consiste à utiliser bindfs https://code.google.com/p/bindfs/ qui est installable via le port:
Sudo port install bindfs
Sudo bindfs ~/source_dir ~/target_dir
s'il n'y a pas de sous-dossier, vous pouvez essayer
ln folder_path /*.* target_folder
cela a fonctionné pour moi sur OSX 10.9