inode eines files ermitteln

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • inode eines files ermitteln

    Hallo,

    hat jemand ne Ahnung wie ich den inode zu einem Pfadnamen finde? Der parent node wär auch interessant.Bisher hab ich nur das rausgefunden:

    Quellcode

    1. struct stat fstatInfo;
    2. int fd;
    3. if( ( fd = open( "/Users/manfred/Desktop/chris", O_RDONLY ) ) == -1 ) {
    4. NSLog (@"open error");return( -1 );
    5. }
    7. if( fstat( fd, &fstatInfo ) == -1 ) {
    8. NSLog (@"stat error");return( -1 );
    9. }
    10. NSLog (@"Node = %i",fstatInfo.st_ino);
    11. close( fd );
    Alles anzeigen
    aber irgendwie scheint mir stat() nicht gerade das Richtige zu sein, zumal ich ja das file nicht immer öffnen will und keine Infos zum parent bekomme.

    Hat jemand Ahnung wie man inodes handelt?

    Danke Manfred
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Mit stat bist du schon auf der richtigen Spur, ohne Öffnen des Files geht's so:

    C-Quellcode

    1. #include <sys/types.h>
    2. #include <sys/stat.h>
    3. #include <stdio.h>
    5. int main() {
    6. struct stat s;
    7. stat("/etc/hosts", &s);
    8. printf("Inode: %d\n", s.st_ino);
    9. }

    Die Parent inode rauszubekommen ist evtl. ein wenig kniffliger. Wenn du den kompletten Pfadnamen hast, kannst du natürlich basename(3) verwenden und darauf nochmal stat anwenden. Ansonsten müsste ich auch mal wühlen, wie das gehen könnte...

  • Es ist die Natur eines Indizes, dass er keinen Parent hat. Ein Index ist "flach".

    Also, straft mich Lügen, ich habe mir das speziell bei HFS(+) nicht angeschaut. Aber soweit ich informiert bin, hat jede Datei auf der Platte eine eindeutige inode#. Und zwar von vorne bis hinten durchgezählt. Daher gibt es keinen Parent inode.

    Natürlich werden inodes als Datei-Index in Verzeichnissen gespeichert -- in beliebig vielen. Welchher ist der Parent? Das ist übertragen so, als ob du fragen würdest, was die Parent-Adresse zu einem Speicherplatz ist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von Tom9811
    Es ist die Natur eines Indizes, dass er keinen Parent hat. Ein Index ist "flach".


    OK, "parent inode" ist arg vekürzt, zugegeben ;-). Die inodes selbst werden natürlich ohne Rücksicht auf die Directorystruktur vergeben, aber die Dateisystem-Hierarchie impliziert ja zu jeder Datei ein übergeordnetes Verzeichnis – und das hat natürlich auch wieder eine inode. Und ich denke, genau die war gesucht...

  • aber die Dateisystem-Hierarchie impliziert ja zu jeder Datei ein übergeordnetes Verzeichnis – und das hat natürlich auch wieder eine inode. Und ich denke, genau die war gesucht...
    Genau!

    Aber ich wuhle hier mittlerweile schon im code der bash :sick: um rauszufinden wie cd .. geht. Kann mir nicht vorstellen, daß hier wirklich an Pfaden (strings) geschnippelt wird.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Neeee, das geht logisch nicht. Das war von mir keine KKorinthenkackerei.

    Schauu, du hast eine Datei mit einem Bild. Diese Datei hat einen inode mit einer inode#, sagen wir 265.

    Wenn diese Datei in einem verzeichnis liegt, so gibt es in dem Verzeichnis (was ja auch nur eine Datei ist) den folgenden eintrag:
    HübschesBild.jpg #265

    Diesen Eintrag kann es aber -auch mit unterschiedlichen Namen- in beliebig vielen Verzeichnissen geben. Du kannst daher nicht sagen, was "der Vater" ist. Das ist einfach keine eindeutige Beziehung. Daher wird das auch nicht im inode gespeichert, wohl aber die Anzahl der Referenzen auf die Datei. Das müsstest du einfach lesen können.

    Bei unixoiden Dateisystemen gibt es keine Struktur der eigentlichen Dateien. Diese wid nur durch den *Inhalt* der Verzeichnisse gebildet.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Original von Tom9811
    ...
    Diesen Eintrag kann es aber -auch mit unterschiedlichen Namen- in beliebig vielen Verzeichnissen geben. Du kannst daher nicht sagen, was "der Vater" ist. Das ist einfach keine eindeutige Beziehung. Daher wird das auch nicht im inode gespeichert, wohl aber die Anzahl der Referenzen auf die Datei. Das müsstest du einfach lesen können.


    Stimmt, hardlinks hatte ich irgendwie (mental) ausgeblendet :-). ACK.

  • Ich bekomme die filesystem events. Nun möchte ich feststellen, ob das gerade geänderte file in einem überwachten Unterverzeichnis ist und geloggt wird. Also ist /Users/manfred/bla/blu/blob/foo.txt ein Unterverzeichnis von /Users/manfred/ . Kann man natürlich über String vergleiche erreichen - was bestimmt nicht gerade wenig kostet.

    Meine Überlegung ist nun den inode von /Users/manfred in der Datenbank zu speichern. Der zu überprüfende Pfad wird von hinten her durchgegangen anhand der inodes. Habe ich einen inode der in der Datenbank ist, kann ich entsprechend eine Aktion ausführen.

    Einen int aus der Datenbank zu fischen dürfte doch um einiges sparsamer sein, als zu schauen ob mein zu überzrüfender Pfad mit einem Pfad aus der Datenbank anfängt.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Ich denke, es kommt eben drauf an.

    Szenario 1: Ich habe 100 Verzeichnisse bei denen ich die Events loggen will und überprüfe einen Pfad der eine "Tiefe" von 5 hat:

    Strings: Ich hol mir die hundert strings und püfe ob mein Pfad mit einem dieser anfängt - hundert Stringvergleiche wenn der Pfad nicht geloggt wird (oder der ensprechende Eintrag ist hinten in der Liste).

    Inodes: Ich muss 5 mal prüfen ob ein integer in der Datenbank ist.

    Szenario 2: Ich habe 1 Verzeichnis bei dem ich die Events loggen will und einen Pfad mit einer Tiefe von 100.

    Strings: 1 stringvergleich.

    Inodes: 100 Intabfragen.

    Was ist wichtiger, ein paar ellenlange Pfade die vielleicht mal etwas länger dauern. Aber wenn ich viele Pfade überwache, komme ich ziemlich ins schwitzen.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Hey, vielleicht geht es doch. Ich habe gerade auf der Toilette im Singh für HFS+ geschmöckert. Der Catalog B-Tree enthält eine "Parent"-Verknüpfung. Hast du den Singh? Dann schau da mal nach.

    Ob man da allerdings irgendwie dran kommt und wie er weitere Referenzen behandelt, habe ich jetzt auf die Schnelle nicht finden können.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • So, HFS+ macht es tatsächlich anders als ein "normales" UFS -- und es geht!

    Amit Singh, Mac OS X Internals, S. 1515:
    "An interesting property of HFS+ is that it allows a Unix pathname of a file system obejct to be determined from its inode number. With the exception of hard links, an object's CNID is used as its inode number form the standpoint of the Unix APIs. Since a thread record connects an object to its parent, a complete pathname can be constructed by repeatedly looking up thread records until the root."

    Es scheint also zu gehen, dass man sich hochhangelt. Jetzt würddte ich nur noch gerne, wie es HFS+ macht, wenn man eine Datei mit einem (weiteren) Hardlink hat und den Original-Parent löscht. Dann müsste der ja umgehangen werden oder der Parent wird einfach nil. Zum ersten müsste er ja wissen, wer die Datei ebenfalls referenziert.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Tom, ich schulde dir ne Rolle Klopapier.

    inode heißt jetzt CNID

    C-Quellcode

    1. #include <stdio.h>
    2. #include <sys/types.h>
    3. #include <Carbon/Carbon.h>
    5. typedef struct {
    6. unsigned char length;
    7. unsigned char characters [255];
    8. } HFSStr255;
    10. int main(int argc, char *argv[])
    11. {
    12. long cnid = -1;
    13. FIDParam pb;
    14. OSStatus result;
    16. cnid = atoi(argv[1]);
    18. pb.ioVRefNum = 0;
    19. pb.ioSrcDirID = -1;
    20. pb.ioFileID = cnid;
    22. if ((result = PBResolveFileIDRefSync((HParmBlkPtr)&pb)) < 0) {
    23. return result;
    24. }
    25. printf ( "%d\n",pb.ioSrcDirID);
    26. return 0;
    27. }
    Alles anzeigen
    Aber die CNID (eindeutige ID im b-tree von HFS+) eines Files scheint nur "bedingt" dem inode zu entsprechen - hardlinks.

    Soweit ich das bisher verstanden habe bekommt ein Hardlink beim anlegen dann einen Eintrag im b-tree. Der hat ne einmalige ID und enthält die ID (was in dem Fall der inode ist) des "Urfiles" (guckst du Seite 1550 und Umgebung)
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Events mal zu loggen lohnt sich. Viele Anwendungen scheinen aus hardlinks eigene Files zu machen :

    Quellcode

    1. // hier erzeuge ich ein file und lege einen hardlink an
    3. 2006-11-19 20:53:17.870 FileHandle[789]Event FSE_CREATE_FILE 2675834 /private/var/root/temp/test.txt
    4. 2006-11-19 20:53:40.983 FileHandle[789] Event FSE_CREATE_FILE 2675834 /private/var/root/temp/link.txt
    6. // via shell (echo) verändere ich den Inhalt der beiden
    8. 2006-11-19 20:54:29.252 FileHandle[789] Event FSE_STAT_CHANGED 2675834 /private/var/root/temp/test.txt
    9. 2006-11-19 20:54:29.254 FileHandle[789] Event FSE_CONTENT_MODIFIED 2675834 /private/var/root/temp/test.txt
    10. 2006-11-19 20:54:44.698 FileHandle[789] Event FSE_STAT_CHANGED 2675834 /private/var/root/temp/test.txt
    11. 2006-11-19 20:54:44.699 FileHandle[789] Event FSE_CONTENT_MODIFIED 2675834 /private/var/root/temp/test.txt
    12. 2006-11-19 20:55:07.847 FileHandle[789] Event FSE_STAT_CHANGED 2675834 /private/var/root/temp/test.txt
    13. 2006-11-19 20:55:07.849 FileHandle[789] Event FSE_CONTENT_MODIFIED 2675834 /private/var/root/temp/test.txt
    14. // beide haben identische inode Nummern
    15. // hier passierts, wenn ich z.B. mit dem Texteditor etwas ändere. Es wird ein temporäres
    16. // file angelegt, das original gelöscht usw. Hardlink ade, ist jetzt abgenabelt.
    18. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_CONTENT_MODIFIED 2675842 /private/var/root/temp/test.txt
    19. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_RENAME 2675842 /private/var/root/temp/.480-185658958-5.txt
    20. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_STAT_CHANGED 2675842 /private/var/root/temp/test.txt
    21. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_RENAME 2675834 /private/var/root/temp/test~.txt
    22. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_RENAME 2675842 /private/var/root/temp/test.txt
    23. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_DELETE 2675834 /private/var/root/temp/test~.txt
    24. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_STAT_CHANGED 2675842 /private/var/root/temp/test.txt
    25. 2006-11-19 20:55:58.259 FileHandle[789] Event FSE_STAT_CHANGED 2675842 /private/var/root/temp/test.txt
    Alles anzeigen
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.