FindFirst soll nur echte Verzeichnisse finden, keine Links

[mschnell]

Dass Hardlinks auf Verzeichnisse verboten sind, wusste ich nicht ! Damit hat Giantics ein Problem weniger .

-Michael

[Giantics]

Ehrlich gesagt war mir gar nicht bewusst, dass es unterschiedliche Links (Hard und Soft) gibt. Danke an creed für die Links!

Habe jetzt eine Lösung gefunden:
Bei SymLinks liefert fplstat in nlink immer 1 zurück, bei normalen Verzeichnen immer mindestens 2.

Code: Alles auswählen

function IsRealDirectory(FilePath, Value: String): Boolean;
  var
    info: stat;
  begin
    Result := false;
    if not ((Value='.') or (Value='..') or (Value='')) then
    begin
      fplstat(FilePath+Value,@info);
      if info.nlink<>1 then Result := true;
    end;
  end;

Vielleicht funktioniert irgendwann auch mal faSymLink wieder, dann kann man sich die zusätzliche Prüfroutine sparen.

Ihr seid super!

[mschnell]

Das ist leider nicht die Lösung !

info.nlink zählt nur die Hardlinks, nicht die Symlinks. Und die Hardlinks brauchst Du beim scannen nicht auszuschließen. Die mehrfach verlinkten Dateien mehrfach zu finden, ist im Normalfall genau das, was man will (nur wenn man z.B. die Gesamtgröße des von den Dateien mit sinnvoller Information belegten Plattenplatzes errechnen will, wird man mehrfach verlinkte Dateien nur einmal zählen wollen). Und Hardlinks auf Directories sind, wie wir beide gerade gelernt haben, ohnehin in Linux (aber nicht in allen Unixen (Mac = ???) verboten. Also kann sind Verzeichnisse auch mit Hardlinks (nicht aber mit Symlinks !) strikt baumförmig und es kann nicht zu Rekursionen kommen.

Das kann bei Symlinks aber passieren ! Und da hilft dann vermutlich nur faSymLink. Wenn das nicht funktioniert, muss man es ans funktionieren bringen (ist schließlich Open Source " !)

-Michael

[pluto]

und was währe wenn du einfach die Ausgabe von ls -l verarbeiten würdes ?
(Währe halt nur eine Notfall Idee)

Was war denn mit der Idee der Dateigröße ?

[Giantics]

Das mit der Dateigröße hat leider nicht hingehauen.
Die Ausgabe von ls kann man natürlich verarbeiten. Allerdings erhält man damit fast die gleichen Infos wie durch die Funktion fpfstat.

info.nlink zählt nur die Hardlinks, nicht die Symlinks. Und die Hardlinks brauchst Du beim scannen nicht auszuschließen. ... Und Hardlinks auf Directories sind, wie wir beide gerade gelernt haben, ohnehin in Linux (aber nicht in allen Unixen (Mac = ???) verboten. Also kann sind Verzeichnisse auch mit Hardlinks (nicht aber mit Symlinks !) strikt baumförmig und es kann nicht zu Rekursionen kommen.

nlink zählt Hardlinks. Stimmt! Diese Überprüfung mache ich jedoch nur bei Verzeichnissen und nicht bei Dateien. Da jedoch, Hardlinks zu Verzeichnissen nicht erlaubt sind, kann der nlink bei Symlinks zu Verzeihnissen nicht größer als 1 werden (zumindest unter Linux). Klar soweit?
Ich habs mal bei mir mit ein paar Versuchen getestet:
ls -l:
lrwxrwxrwx 1 thomas thomas 4 2007-11-18 18:07 ab -> PDF/
lrwxrwxrwx 1 thomas thomas 2 2007-11-18 18:09 bc -> ab
lrwxrwxrwx 1 thomas thomas 4 2007-11-18 18:14 cd -> PDF/
drwxr-xr-x 3 thomas thomas 4096 2007-11-12 21:50 Linux
drwx------ 2 thomas thomas 4096 2007-11-18 18:08 PDF

Wenn du es schaffst einen SymLink zu einem Verzeichnis mit nlink>1 zu erstellen, dann gib mir bitte Bescheid
Demnach sollte diese Methode ganz OK und sicher sein, was meinst du?

Und da hilft dann vermutlich nur faSymLink. Wenn das nicht funktioniert, muss man es ans funktionieren bringen (ist schließlich Open Source " !)

Ich nehm's mal in Angriff.

[pluto]

Ich habe in den Oben geposteten links gelesen wenn fpfstat. (vermutlich) den wert 1 hat ist es kein link, sobald er hörer ist es ein Link. Spielt ja keine roll was für ein Link... oder ?

[Giantics]

Ich habe in den Oben geposteten links gelesen wenn fpfstat. (vermutlich) den wert 1 hat ist es kein link, sobald er hörer ist es ein Link. Spielt ja keine roll was für ein Link... oder ?

Wernn nlink>1, dann existieren mehrere Hardlinks. Da Hardlinks (manuell) auf Verzeichnisse jedoch nicht erlaubt sind, muss ich die schonmal nicht rausfiltern, nur noch Softlinks. Und Softlinks auf Verzeichnise haben wohl immer nlink=1 (getestet), Verzeichnisse selbst 2 oder mehr (2+Anzahl der Unterverzeichnisse)
Ich könnte mir vorstellen, dass das so ist:
Beispiel: Ein Verzeichnis mit zwei Unterordnern:

Code: Alles auswählen

Ordner1    //1
 ->.       //2
 ->..
 ->Unterordner1
   ->.
   ->..    //3
 ->Unterordner2
   ->.
   ->..    //4

ergibt 4 "Hardlinks" (oder was auch immer), die auf "Ordner1" verweisen.
Kannst ja mal selbst testen. "ls -l" zeigt den nlink Wert an.
Verwirrung komplett

[schnullerbacke]

Um die Backtracer (.;..) auszuschließen musst man die gesondert ausfiltern. Was die Symlinks angeht, ist das fast logisch, das die rekursiv laufen. Für ein beliebiges Programm verzweigen die ja in das physikalische Verzeichnis. Damit sucht er rekursiv dann auch in denen weiter. Die ExtFileBrowser-Komponents schließen das aus.

Aber danke für den Hinweis, ich seh mir die Dinger mit 0.9.24/2.2.0 nochmal an, hab das gerade erst installiert.

[mschnell]

Jeder Symlink ist eine Datei. Also ist "." und ".." auf keinen Fall ein Symlink.

Hardlinks auf Verzeichnisse sind verboten (info.nlink ist immer 1, wie Giantics getestet hat). Also ist "." und ".." auf keinen Fall ein Hardlink.

Was ist es dann ?!?!?

[pluto]

Sachen die Raußgefiltern werden müssen wenn man sie nicht haben möchte *G*

Ich denke das wird auch eine Form von einem Link sein.

[Giantics]

...Hardlinks auf Verzeichnisse sind verboten (info.nlink ist immer 1, wie Giantics getestet hat). Also ist "." und ".." auf keinen Fall ein Hardlink.

Was ist es dann ?!?!?

Sehe ich nicht ganz so Ich habe gerade nochmal recherchiert, nlink ist definitiv die Anzahl der Hardlinks. Demnach sind wohl nur manuelle Hardlinks auf Verzeichnisse verboten.
Vom System wird wohl automatisch noch einer als "." angelegt. Genauso für jeden Unterordner: Die befinden sich dann im Unterordner und heißen ".."
Das erklärt warum jeder richtige Ordner mindestens nlink=2 hat.
Ich habe gerade nachgeprüft was für nlinks die "." und ".." Verzeichnisse haben: "." hat dasselbe nlink wie das zugehörige Verzeichnis! Und die ".."-Verzeichnisse haben dieselben Anzahl an nlinks wie das übergeordnete Verzeichnis.
Das deckt sich auch mit der Ausgabe von "ls -l"
Und da nlink bei Symlinks=1 ist, bedeutet dann ja nur, dass darin keine "." oder ".." existieren.

Beispiel:
thomas@thomas-desktop:/home$ ls -l -a
drwxr-xr-x 5 root root 4096 2007-10-08 11:47 .
drwxr-xr-x 21 root root 4096 2007-10-20 15:00 ..
drwxr-xr-x 59 thomas thomas 8192 2007-11-19 17:19 thomas

thomas@thomas-desktop:/home/thomas$ ls -l -a
drwxr-xr-x 59 thomas thomas 8192 2007-11-19 17:19 .
drwxr-xr-x 5 root root 4096 2007-10-08 11:47 ..

Das alles hat mich jetzt davon überzeugt, dass "." und ".." definitiv richtige Hardlinks sind.

[pluto]

Ja.... dann währe die Frage ja geklärt oder ? übrings eine Ähnliche Frage hatte ich auch schon gestellt. evlt. kann ich mal die Antwort hier in meinem Projekt(Eigenes Öffnen Dialog) einbauen.).. *G*

Nochmal: 59 heißt also auf thomas zeigen 59 (hard) Links

[creed steiger]

. und .. sind eigentlich Hardlinks (aber auch wieder nicht)

http://www.nitidelo.de/linux.php?text=dateitypen" onclick="window.open(this.href);return false;

http://lwn.net/Articles/249607/" onclick="window.open(this.href);return false;

http://linuxgazette.net/105/pitcher.html" onclick="window.open(this.href);return false;

[Giantics]

Ja.... dann währe die Frage ja geklärt oder ? übrings eine Ähnliche Frage hatte ich auch schon gestellt. evlt. kann ich mal die Antwort hier in meinem Projekt(Eigenes Öffnen Dialog) einbauen.).. *G*

Nochmal: 59 heißt also auf thomas zeigen 59 (hard) Links

Ja (57 Unterordner drin).

Frage is somit in meinen Augen geklärt

Falls du für dein Projekt die oben von mir gepostete Funktion "IsRealDirectory" gebrauchen kannst, die funktioniert bei mir, darfst dich gerne bedienen (Unit BaseUnix einbinden).

Gruß
Thomas

[pluto]

Gut zu Wissen *freu*