Comment créer un lien dur (par opposition à un lien symbolique ou à un alias Mac OS) sous 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 aux autres environnements Unix, permet la liaison en dur aux dossiers (ceci est utilisé pour Time Machine, par exemple), mais je ne sais pas comment le faire moi-même.
Réponses
Trop de publicités?
Bob
Points
321
Je suis d'accord que le fait de relier des dossiers/répertoires peuvent causer des problèmes si vous ne faites pas attention, mais ils ont un avantage certain Temps Machine est un parfait exemple. Sans eux, il ne serait tout simplement pas pratique que la duplication des versions redondantes de fichiers très rapidement consommer le plus de disques.
Snow Leopard pouvez créer des liens en dur vers des répertoires aussi longtemps que vous suivez Amit Singh six règles:
- Le système de fichiers doit être journalisé HFS+.
- Les répertoires parents de la source et de destination doivent être différentes.
- La source du parent ne doit pas être le répertoire racine.
- La destination ne doit pas être dans le répertoire racine.
- La destination ne doit pas être un descendant de la source.
- La destination ne doit pas avoir un ancêtre qui est un annuaire de lien en dur.
Il n'est donc pas de corriger, à tout ce que Snow Leopard a perdu la capacité de créer des liens en dur pour des dossiers.
J'ai juste vérifié que link/unlink faire un travail sur Snow Leopard - aussi longtemps que vous suivez les six des règles. Je l'ai essayé et il fonctionne très bien sur mon Snow Leopard 10.6.6 système - essayé sur le volume de démarrage et sur un USB séparé de volume externe et il a bien fonctionné dans les deux cas.
Ici, c'est le "hunlink.c" programme:
#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
Alors, soyez prudent si vous essayez, n'oubliez pas de suivre les règles et l'utilisation hlink pour créer ces liens en dur et l'utilisation hunlink pour supprimer le lien en dur par la suite. Et n'oubliez pas de document ce que vous avez fait pour plus tard ou pour quelqu'un d'autre qui aurait besoin de savoir.
Un autre "piège" que je viens d'apprendre au sujet de ces "liens en dur" dans les dossiers. Lorsque vous créez eux, il y a vraiment beaucoup de choses qui se passe "derrière le rideau" de Mac OS X. On a vraiment important est que le dossier que vous créez le lien est vraiment déplacé vers un super-magique super-dossier caché nommé /.HFS+ salle de Répertoire de Données%000d/dir_xxx où xxx est le numéro d'inœud de la "source_folder" - rappelez-vous que le format de la commande est
hlink source_folder target_folder
Donc, de ce fait, vous devez faire attention de ne pas avoir tous les fichiers ouverts dans le "source_folder" parce que si vous le faites, qu'ils ont juste été déplacés vers le super-magique dossier et vous aurez probablement un problème si vous essayez d'enregistrer les modifications apportées à ces fichiers qui ont été ouverts dans le "source_folder". Ce qui m'est arrivé une couple de fois, jusqu'à ce qu'il m'est apparu ce qui se passait et la solution est assez simple. J'ai remarqué que tu ne pouvais pas faire un "ls-la" commande plus longtemps sans arriver drôle erreurs pour tous les dossiers/répertoires qui ont été à l'origine, "source_folder" mais vous pourriez faire un "ls" de commande et tous l'air bien.
Si vous exécutez "Vérifier le disque" dans "Utilitaire de Disque" de programme, vous remarquerez sans doute qu'il se plaint et donne un "bitmap du Volume des besoins mineurs de réparation pour les orphelins blocs" qui est-ce qui s'est passé avec la création de la super-magique dossier et le mouvement de la "source_folder" pour elle.
Si vous vous trouvez dans cette situation avec des "orphelins de blocs", d'abord enregistrer les fichiers modifiés à un autre emplacement temporaire pas dans le volume contenant le "source_folder" de l'arbre, puis utiliser "Utilitaire de Disque" de démonter et de remonter le volume qui contient le "source_folder" ou tout simplement redémarrer l'ordinateur. Ensuite, copiez les fichiers que vous avez enregistré à l'emplacement temporaire vers leur emplacement d'origine et vous devriez être de retour dans les affaires. C'est ce qui a fonctionné pour moi, ne peut donc pas garantir que cela fonctionne pour vous aussi. Donc, il pourrait être une bonne idée pour essayer de volume, vous disposez d'une bonne sauvegarde de juste au cas où.
Il semble très étrange que tout cela surcharge se produit juste pour la simple tâche de créer un lien en dur vers un dossier. Quelqu'un a une idée de pourquoi Mac OS X va tout cet effort pour ce lien en dur création de dossiers? A-t-elle quelque chose à voir avec le fait que c'est un "journalisé" système de fichiers?
J'ai découvert l'info sur le super-magique, super endroit caché par la lecture de Amit Singh explication de son "hfsdebug" de l'utilitaire. Si vous voulez plus de détails, consultez son site web à l' Amit Singh hfsdebug utilitaire. C'est une pièce très intéressante de logiciel et va vous dire beaucoup de détails sur HFS+ systèmes de fichiers. C'est gratuit et je vous encourage à le télécharger et de l'essayer. Il n'est plus pris en charge, mais il fonctionne toujours sur Snow Leopard et Leopard - en fait toutes les HFS+ système pris en charge. Vous ne pouvez pas vraiment faire de mal avec elle car c'est une "lecture seule" outil - il est donc idéal pour une utilisation à regarder certains détails du système de fichiers.
Encore une question à propos de ces "liens en dur vers des dossiers" - une fois que vous créer un et le super-magique super-secret caché, le dossier est créé, il est là pour de bon. Même si vous dissociez le dossier qui l'a causé d'être créé en premier lieu, cette magie dossier reste autour. Je ne sais pas pourquoi, mais il n'a certainement. Vous pouvez utiliser "hfsdebug" de la trouver si vous souhaitez l'essayer. Vous pouvez également utiliser "hfsdebug" pour savoir combien de ces "liens en dur vers des dossiers" existent sur un disque. Pour plus de détails reportez-vous à Amit l'article sur le "hfsdebug" de l'utilitaire.
Il a aussi une autre plus récente de l'utilitaire qui est pris en charge, mais les coûts. Il est appelé fileXray et les coûts de 79 $pour une personne sur n'importe quel nombre d'ordinateurs dans le même ménage pour un personnel non-type de licence. Il dispose d'un vaste 173-page Guide de l'Utilisateur que vous pouvez télécharger pour voir ce qu'il peut faire avant d'acheter. Malheureusement, il n'existe pas de version d'essai, afin de lire le manuel et consultez le site web pour plus de détails, voir si il peut vous aider à sortir d'une confiture. Apprendre tous les détails à ce sujet sur leur site web - voir fileXray site web pour plus d'info.
Il ya un couple de questions que vous devez être conscient lors de l'utilisation de ces liens en dur vers des dossiers. Si le volume qu'ils sont créés sur est monté sur un client distant, il peut y avoir des problèmes importants, en fonction de la façon dont ils sont montés. Si vous utilisez l'AFP, pour monter le volume à un client distant, il y a de gros problèmes comme n'importe quel dossier qui dispose actuellement d'un lien en dur elle n'a jamais eu un, mais supprimé ultérieurement, ne pourra plus être utilisé comme tout le bas des dossiers de niveau (mais pas les fichiers) est inaccessible depuis le Finder ou une fenêtre de Terminal. Si vous essayez de faire un simple "ls -lR de la commande", il échouera et vous donner "ls: xxx: Aucun fichier ou répertoire de" messages d'erreur pour tous les dossiers. Si vous utilisez une fenêtre de recherche pour parcourir l'arborescence des répertoires du volume à distance, les dossiers qui sont dans le dossier qui a eu ou qui a un lien en dur elle vont tout simplement disparaître sans aucune erreur lorsque vous cliquez 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 aviez un serveur NFS sur le système qui a le volume d'un local de système de fichier HFS+). Les détails sur la façon d'utiliser NFS pour monter les volumes ne sont pas fournis ici. J'ai utilisé un beau programme du Dr Marcel Bresink appelé "NFS Manager" pour aider avec le montage NFS sur le serveur et le client. Vous pouvez l'obtenir à partir de son site web, il suffit de chercher "Bresink NFS Manager" dans votre moteur de recherche préféré, mais il a une version d'essai gratuite de sorte que vous pouvez essayer avant d'acheter. C'est pas un gros problème si vous voulez apprendre à faire les montages NFS, mais le "NFS Manager", il est assez facile de mettre les choses en place et à ajuster les différents réglages pour aider à l'optimiser. Il a plusieurs autres soigné utilitaires Mac OS X qui sont d'un prix très raisonnable appelée "Hardware Monitor" qui vous permet de surveiller et tracer le graphique de toutes sortes de choses comme l'utilisation de l'énergie, de la température du PROCESSEUR, la vitesse de fans et beaucoup d'autres variables pour à la fois localement et à distance les systèmes Mac sur de longues périodes de temps (de quelques minutes à quelques jours). Certainement la peine de vérifier si vous êtes à portée de main les services publics.
Une chose que j'ai remarquer, c'est que les transferts de fichiers NFS ont été d'environ 20% plus lent que de le faire via l'AFP, mais votre "kilométrage peut varier", donc pas de garanties, d'une façon ou l'autre, mais je préfère avoir quelque chose qui fonctionne, même si je dois payer 20% de performances par rapport à rien du tout.
Apple est conscient des problèmes avec des liens en dur et distant AFP systèmes de fichiers, et ils se réfèrent à lui comme le "implémentation de limitation" de l'AFP client - je préfère l'appeler de ce que cela me semble être UN BUG!!! Je peux seulement espérer que la prochaine version de Mac OS X résout le problème, comme je l'ai vraiment ayant la capacité d'utiliser des liens en dur vers des dossiers lorsque cela a du sens.
Ces notes sont de mon opinion personnelle et je ne fais pas de garantie quant à leur exactitude, afin de les utiliser à vos propres risques. Avoir une bonne sauvegarde avant de jouer avec ces "liens en dur vers des dossiers" juste au cas où quelque chose d'imprévu se produit. Mais j'espère que vous vous amusez si vous décidez de regarder un peu plus dans ce qui est 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 <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 construisez Terminal.app avec:
$ gcc -o hlink hlink.c -Wall
Rich
Points
87
Piffle. 10.5, il vous l'indique dans la page de man 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
Donner votre mot de passe, et vous n'êtes pas encore fait. Vous n'avez pas de document, as-tu? Vous devez document dur liée répertoires; même si c'est un seul utilisateur de la machine.
La suppression est une autre histoire: si vous allez à ce sujet de la manière habituelle pour supprimer des répertoires, vous allez supprimer le contenu. Donc, vous devez rompre le lien de l'annuaire:
unlink new_hard_link
Il n'. Espérons que vous n'avez pas l'épave de votre système de fichiers!
Jesper Rønn-Jensen
Points
15212
Mon cas a été que j'ai découvert qu'à partir d'une machine virtuelle windows, je ne peux pas suivre les liens symboliques. (j'ai voulu tester quelques pages HTML dans Internet Explorer). Et ma structure de répertoire avaient des liens symboliques pour les CSS et les images des dossiers.
Ma solution de contournement pour résoudre le problème est une approche différente de celle des autres réponses implicites. J'ai utilisé rsync pour créer une copie du dossier. Rsync peut résoudre les liens symboliques et copier les fichiers liés en place.
Cela a résolu mon problème sans l'aide de liens en dur vers des répertoires. Et c'est en fait une solution facile si vous êtes en train de travailler sur un petit ensemble de fichiers.
rsync -av --copy-dirlinks --delete ../htmlguide ~/src/
