›

Liens symboliques

GGGG Membre
20:44 modifié dans API AppKit #1
Bonjour à  tous,
je cherche à  savoir s'il existe une méthode qui retourne un booléen sur un lien symbolique.
En gros j'aimerai via NSFileManager savoir si le fichier actuel est  un lien symbolique ou non.
Vous savez ou je peux trouver ça ?
Bon weekend à  tous ;)

Réponses

  • SystemSystem
    20:44 modifié #2
    Si tu utilises "fileAttributesAtPath:" de fileManager et que tu regardes ensuite à  la clé "NSFileType" puis à  la clé "NSFileTypeSymbolicLink" ça devrait ptete le faire ?  ???
  • TchouboudouTchouboudou Membre
    20:44 modifié #3
    Moi :adios!: ! Question ! C'est quoi un lien symbolique ?
  • MulotMulot Membre
    20:44 modifié #4
    Un lien symbolique sert entre autre à  "pointer" sur un fichier ou un autre répertoire. Par exemple, sur des machine dual boot, il est courant de faire un lien symbolique dans son home Unix vers son home windows, pour pouvoir y acceder. Au contraire du hard link qui lui doit être utilsié avec précautions. Sinon un bon petit man t'en apprendra plus. (man ln)
  • tabliertablier Membre
    20:44 modifié #5
    Pour compléter la réponse de mulot, il faut noter qu'un "Alias" est un fichier ordinaire qui n'a rien à  voir avec les liens UNIX. Il contient les références du fichier qu'il représente sous une forme exploitable par le filemanager de Mac OSX.
    La différence (lien symbolique - Alias) est visible lorsque l'on déplace l'original. Le lien symbolique perd la liaison à  l'original, alors que l'alias ne perd pas la liaison.
    Pour le hard link, je ne sais pas ce qui se passe si l'on déplace l'original. D'après le "man" on ne peut pas faire de différence entre l'original et le hard link!  ???
  • schlumschlum Membre
    20:44 modifié #6
    dans 1197139873:

    Pour compléter la réponse de mulot, il faut noter qu'un "Alias" est un fichier ordinaire qui n'a rien à  voir avec les liens UNIX. Il contient les références du fichier qu'il représente sous une forme exploitable par le filemanager de Mac OSX.
    La différence (lien symbolique - Alias) est visible lorsque l'on déplace l'original. Le lien symbolique perd la liaison à  l'original, alors que l'alias ne perd pas la liaison.
    Pour le hard link, je ne sais pas ce qui se passe si l'on déplace l'original. D'après le "man" on ne peut pas faire de différence entre l'original et le hard link!  ???


    Un alias est un fichier de ressources pures... Par contre, t'es sûr de ton coup pour le déplacement de l'original ??
    Un hard link c'est un lien directement sur l'inode. On ne peut même pas parler d'"original" du coup  ;)
    Quant au symlink, c'est un fichier qui contient juste le chemin absolu ou relatif de l'original. Ce chemin est stocké dans le datafork, mais inaccessible aux accès standard.
  • tabliertablier Membre
    20:44 modifié #7
    Je viens de faire l'expérience:
    je fais un fichier texte dans un dossier quelconque. J'en fais un alias que je mets sur le bureau. Puis je balade l'original de dossier en dossier et je vérifie le lien en demandant les informations sur l'alias après chaque déplacement. Je confirme que ça marche, le lien est maintenu (par le filemanager je pense).
    Mais ça ne marche plus si l'original est détruit et recréer ailleurs!!

    Effectivement: ouvert sous un editeur de ressource, les alias ont le datafork vide et le resourcefork contient deux ressources: "alis" et "icns". Dans "alis" ont trouve le chemin courant du fichier original, et dans "icns" l'icone du fichier original.
  • schlumschlum Membre
    20:44 modifié #8
    Mouais, ça doit être sous conditions ces histoires de déplacements... ça m'étonne quand même. À moins que ça ne fonctionne avec Spotlight / TimeMachine (/dev/fsevents), le système n'a pas de notifications quand quelque-chose bouge... Il faudrait faire des tests plus poussés, genre déplacement avec "mv" dans le terminal, déplacement via une autre machine en passant par une connexion AFP...
    De quel "filemanager" parles-tu ?
  • SystemSystem
    décembre 2007 modifié #9
    Et si l'alias conservait justement l'inode ;)

    Edit -- non, je n'ai rien dit puisqu'on en déplacant/renommant (même via mv) le fichier on voit bien que la date de modification de l'alias change...

    Edit 2 -- ok, en déplacant avec la touche pomme sur un autre volume (en dehors de mon bureau filevault pour être exact) l'alias est perdu. Mais si on rien de l'autre volume vers le bureau l'alias retrouve son petit alors que l'inode à  changer...
  • tabliertablier Membre
    20:44 modifié #10
    Je connais MacOS depuis la version 4 ou 6 je pense (je sais, c'est antédiluvien  :P ). Les alias, depuis qu'ils existent sous MacOS, sont toujours restés connectés à  leurs originaux!
    J'ai reéssayé sous 9.2.2 sur un vieux G3, les alias restent connectés quand on déplace l'original (deplacer sous 9.2.2: glisser-deposer avec la touche pomme appuyé).
    Fais la manip que j'ai précédemment indiquée pour t'en convaincre. Je pense que la limite de fonctionnement est la machine elle-même (mais qui sait?)
    Le file manager dont je parle est celui de MacOS et non pas de celui d'UNIX (l'un s'appuie sur l'autre mais peut avoir des fonctions supplémentaires).
  • AliGatorAliGator Membre, Modérateur
    décembre 2007 modifié #11
    A ma connaissance :
    • Les alias existent depuis belle lurette sous MacOS, bien avant MacOSX. Ce sont des fichiers de ressources (les informations sur le fichier original etc se trouvent dans le resource fork). Il sont, il me semble, basé sur les "FSSpec" de Carbon, permettant d'identifier un fichier de façon unique indépendamment de son path (chemin d'accès). C'est pour cela qu'il ne perd pas la trace de l'original, et que lorsqu'on fait un alias vers par exemple un fichier d'un CD-ROM ou d'un disque externe, si plus tard on essaye d'ouvrir l'alias alors que le support amovible en question n'est pas monté, il nous demande de le monter...
    • Les liens UNIX sont un peu équivalents aux alias, grosso modo, mais viennent du monde UNIX. Ils sont de 2 types : "liens symboliques" et "hard links".
      • Les liens symboliques sont très simples : ce sont des fichiers donc le seul contenu est le chemin d'accès (POSIX path) vers l'original. Ils pointent donc vers un emplacement dans la hiérarchie du filesystem. Si l'original est déplacé, le lien symbolique ne marchera plus. Si on recrée un autre fichier du même nom que l'ancien original et au même emplacement, le lien symbolique pointera sur ce nouveau fichier et non plus sur l'ancien...
      • Les "hard links" ne sont qu'une référence de plus vers l'inode d'un fichier. En effet, en fichier UNIX, en règle générale, n'est qu'un inode pointant vers des données disque. Chaque fichier n'est qu'un nom pour accéder à  cet emplacement de fichier. Un hard link n'est qu'un nom supplémentaire vers cet emplacement de fichier.
        Donc quand on crée un hard link B vers un fichier A, il est ensuite strictement équivalent de parler de A ou de B : les deux pointent vers les mêmes données, ont les mêmes droits d'accès, ils sont indistingables l'un de l'autre. Un changement sur A affectera B, et vice-versa. On peut même ensuite supprimer le fichier A (qui était, à  l'origine, le pointeur original vers les données), il restera toujours B qui pointe vers les données, qui ne seront donc pas effacées du disque.
        En gros, un hard link, c'est une sorte de "retain" sur des données du disque (sur un inode en fait) : en créant un hard link, on augmente le "retain count" vers l'emplacement des données disque  :P
        D'ailleurs, quand on tape "ls -l" dans le terminal pour avoir un listing détaillé d'un répertoire, la 2e colonne (celle après la colonne des droits UNIX rwxrwxrwx) indique le "inode count" donc le nombre de liens symboliques pointant vers le même espace disque que le fichier en question.
  • schlumschlum Membre
    20:44 modifié #12
    dans 1197193024:
    Le file manager dont je parle est celui de MacOS et non pas de celui d'UNIX (l'un s'appuie sur l'autre mais peut avoir des fonctions supplémentaires).


    Ah tu parles donc de la gestion de fichiers en Carbon, dont le Finder est le digne dernier représentant  :P (même les applications Cocoa passent par la couche Unix maintenant  ;) )

    Et pourtant cette couche Carbon est bien plus puissante... Un simple test :
    - Faire un dossier dont le nom contient 255 "a" via le Finder
    - Dedans faire un dossier donc le nom contient 255 "b"
    - ... "c"
    - ... "d"

    Essayez de sauvegarder quelque-chose dans le dossier "ddd..." avec une application Cocoa, vous vous ferez jeter ! (en UNIX, les limitations sont de 255 caractères UTF-8 pour les noms de fichiers, et 1023 caractères UTF-8 pour le path ; avec la couche Carbon, ce sont directement les limitations HFS+ : 255 caractères UTF-16 décomposé pour les noms de fichiers, pas de limitation pour la taille du path !)

  • tabliertablier Membre
    20:44 modifié #13
    Je crois que ce n'est pas propre à  "Carbon" mais que c'est dans l'OS lui-même car "Carbon" est récent (relativement) et comme le précise implicitement Aligator le comportement des alias existait bien avant "Carbon". Carbon a dû apparaitre avec MacOS 8.6 ou 9.0.
    A ce que je crois savoir et me rappeler: Carbon est une couche qui permettait à  des programmeurs Mac traditionnels de faire des applications fonctionnant dans les deux mondes (MacOS et Mac OSX). Son écriture a exigé une ré-écriture de certains appels système pour les rendre ré-entrant et la suppression d'appels jamais utilisés.
  • schlumschlum Membre
    20:44 modifié #14
    Aliases.h fait partie de CarbonCore  :P
    Donc à  priori c'est une couche Carbon qui gère les alias maintenant.

    Il y a dedans pas mal d'explications sur le fonctionnement des alias d'ailleurs...
    C'est basé sur plusieurs systèmes de recherche.

    enum {<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /* define alias resolution action rules mask */<br />&nbsp; kARMMountVol&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000001, /* mount the volume automatically */<br />&nbsp; kARMNoUI&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000002, /* no user interface allowed during resolution */<br />&nbsp; kARMMultVols&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000008, /* search on multiple volumes */<br />&nbsp; kARMSearch&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000100, /* search quickly */<br />&nbsp; kARMSearchMore&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000200, /* search further */<br />&nbsp; kARMSearchRelFirst&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000400, /* search target on a relative path first */<br />&nbsp; kARMTryFileIDFirst&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000800 /* search by file id before path */<br />};
  • AntilogAntilog Membre
    20:44 modifié #15
    dans 1197366510:

    Aliases.h fait partie de CarbonCore  :P
    Donc à  priori c'est une couche Carbon qui gère les alias maintenant.
    []


    Oui, dans le sens où tout ce qui est utilisable de Mac OS "classique" dans OSX a été défini dans Carbon
  • psychoh13psychoh13 Mothership Developer Membre
    20:44 modifié #16
    dans 1197247940:

    dans 1197193024:
    Le file manager dont je parle est celui de MacOS et non pas de celui d'UNIX (l'un s'appuie sur l'autre mais peut avoir des fonctions supplémentaires).


    Ah tu parles donc de la gestion de fichiers en Carbon, dont le Finder est le digne dernier représentant  :P (même les applications Cocoa passent par la couche Unix maintenant  ;) )

    Et pourtant cette couche Carbon est bien plus puissante... Un simple test :
    - Faire un dossier dont le nom contient 255 "a" via le Finder
    - Dedans faire un dossier donc le nom contient 255 "b"
    - ... "c"
    - ... "d"

    Essayez de sauvegarder quelque-chose dans le dossier "ddd..." avec une application Cocoa, vous vous ferez jeter ! (en UNIX, les limitations sont de 255 caractères UTF-8 pour les noms de fichiers, et 1023 caractères UTF-8 pour le path ; avec la couche Carbon, ce sont directement les limitations HFS+ : 255 caractères UTF-16 décomposé pour les noms de fichiers, pas de limitation pour la taille du path !)



    Il semblerait dans Leopard que le Finder a été aligné sur le reste, impossible de faire ce que tu disais directement avec le Finder... Erreur -43 quand t'essayes de faire le dossier dddddd...
  • schlumschlum Membre
    décembre 2007 modifié #17
    Ah ? Et en utilisant la vieille interface Carbon des FSSpec et FSRef, on peut ?
    je serais curieux de savoir  8--)

    #import &lt;Foundation/Foundation.h&gt;<br /><br />int main (int argc, const char * argv&#91;]) {<br />    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];<br /><br />	FSRef ref,ref2;<br />	OSStatus status;<br />	status = FSPathMakeRef((const UInt8*)[[@&quot;~/Desktop&quot; stringByExpandingTildeInPath] fileSystemRepresentation],&amp;ref,NULL);<br />    if(status!=noErr) {<br />		NSLog(@&quot;Error by getting FSRef (%d)&quot;,status);<br />		return 1;<br />	}<br />	OSErr err;<br />	UniChar name[255];<br />	int i;<br />	for(i=0;i&lt;255;++i)<br />		name[i] = 0x20AC;<br />	for(i=0;i&lt;10;++i) {<br />		err = FSCreateDirectoryUnicode(&amp;ref,255,name,kFSCatInfoNone,NULL,&amp;ref2,NULL,NULL);<br />		if(err!=noErr) {<br />			NSLog(@&quot;Error creating directory (%d)&quot;,err);<br />			return 1;<br />		}<br />		ref = ref2;<br />	}<br />	<br />    [pool release];<br />    return 0;<br />}



    [Edit] Avant qu'on ne me pose la question, c'est sensé créer sur le bureau une série de 10 dossiers imbriqués dont les noms sont formés de 255 caractères "€"
  • psychoh13psychoh13 Mothership Developer Membre
    20:44 modifié #18
    Non ça balance, là  aussi, une erreur de type -43...
  • schlumschlum Membre
    20:44 modifié #19
    Merci 
    Marrant, ils ont harmonisé tout ça à  la sauce UNIX en bridant le FileSystem, mais -43 c'est fnfErr (File Not Found) ; donc correspond pas du tout à  l'erreur que ça devrait être.

    Il n'arrive même pas à  en créer un ? (limitation 255 bytes en UTF-8 décomposé au niveau UNIX, ce qui donnait avec "ls" par exemple un nom tronqué finissant par # + inode en hexadécimal)

    Enfin j'imagine que si on le crée sous Tiger et qu'on boote sous Leopard, il ne va pas détruire les path trop longs quand même.

    Il faudrait tester dans le terminal à  coup de mkdir / cd voir si on peut créer un path > 1024  ???

    Je ferai quelques tests demain au boulot sur ma partition Leopard.
  • psychoh13psychoh13 Mothership Developer Membre
    20:44 modifié #20
    Je ne pense pas qu'il détruise les paths trop long, mais à  mon avis tu ne pourras plus y accéder.
  • schlumschlum Membre
    20:44 modifié #21
    Et ça, ça passe ou ça casse ?  :o

    #include &lt;stdio.h&gt;<br />#include &lt;stdlib.h&gt;<br />#include &lt;unistd.h&gt;<br />#include &lt;errno.h&gt;<br /><br />int main (int argc, const char * argv&#91;]) {<br />&nbsp; &nbsp; int i,res;<br />	for(i=0;i&lt;200;++i) {<br />		res = mkdir(&quot;aaaaaaaaaa&quot;,0755);<br />		if(res!=0&amp;&amp;errno!=EEXIST) {<br />			printf(&quot;mkdir %d failed (%d)&#092;n&quot;,i,errno);<br />			exit(1);<br />		}<br />		res = chdir(&quot;aaaaaaaaaa&quot;);<br />		if(res!=0) {<br />			printf(&quot;chdir %d failed (%d)&#092;n&quot;,i,errno);<br />			exit(1);<br />		}<br />	}<br />&nbsp; &nbsp; return 0;<br />}

  • psychoh13psychoh13 Mothership Developer Membre
    20:44 modifié #22
    Apparemment ça passe, même avec i < 300, mais bizarrement la corbeille est incapable de supprimer tous les dossiers, je suis obligé de passer par le terminal en faisait plusieurs rm -Rf aaaaaaaaaa, jusqu'à  qu'il n'indique qu'un seul dossier qui n'est pas vide, et ensuite je fais rm -R aaaaaaaaaa.
  • schlumschlum Membre
    décembre 2007 modifié #23
    J'avais essayé avec i<100000, et ça finissait par planter pour avoir rempli le buffer des fichiers ouverts du FS au bout de 31825 ...  :P

    mkdir 31825 failed (23)


    Je ne sais pas s'il y a une limite au niveau du FS pour les path.
Connectez-vous ou Inscrivez-vous pour répondre.