FindFirst soll nur echte Verzeichnisse finden, keine Links

[Giantics]

Hallo,

ich habe bei einem Programm eine rekursive Datei-Auflistung (mit FindFirst/FindNext) eingebaut. In einigen Ordnern befinden sich jedoch Links zu Verzeichnissen wie "/". Dadurch kommt die Auflist-Funktion in eine Endlosschleife. Wie kann ich herausfinden, ob der bei FindFirst gefundene Ordner echt oder nur ein Link ist?

Gruß
Thomas

[theo]

http://www.freepascal.org/docs-html/rtl ... mlink.html" onclick="window.open(this.href);return false;

[Giantics]

Das hört sich schon gut an. Ich kannte das Attribut nicht.
Leider haben bei mir alle Ordner und Links das Attribut 48 (also faDirectory +faArchive).
Funktioniert das bei dir? (Oder muss ich das anders anwenden?)

Code: Alles auswählen

if (FindFirst(FilePath+'*',faDirectory,SR)=0) then     
  repeat
    if ((faDirectory or faSymLink) and SR.Attr)=faDirectory then
    begin 
      // hier kommen auch Links an, alles mit SR.Attr=48
    end;
  until FindNext(SR)<>0;

[af0815]

Vielleicht hilft dir auch die Durchsicht von uFileMisc von schnullerbacke. Ist im neuen SVN Snapshoot (Version 64)von LazSnippets zu finden. Den Link dazu findest du am Portal links mitte.

[Giantics]

Vielleicht hilft dir auch die Durchsicht von uFileMisc von schnullerbacke. Ist im neuen SVN Snapshoot (Version 64)von LazSnippets zu finden. Den Link dazu findest du am Portal links mitte.

Hi, habe mir die Datei mitsamt zugehörigem Beispielprogramm mal angesehen. Das Beispiel soll doch eine ein bestimmtes Verzeichnis rekursiv nach einer Datei durchsuchen können, oder?
Selbst hier funktioniert das nur, wenn die Datei im Startverzeichnis ist. Wurde die Funktion mal mit dem aktuellen FreePascal/Lazarus getestet?

Meine rekurisve Suchfunktion hatte nämlich gesten auch noch ohne Aufhängen funktioniert. Das Problem, mit den Links tauchte erst heute nach dem Update auf FP2.2 und L0.9.24 auf.

[mschnell]

faSymLink unterscheidet nur symbolische Links. Es gibt keine Möglichkeit HardLinks zu erkennen, weil alle Links auf einen Inode gleichwertig sind.

-Michael

[af0815]

Hi, habe mir die Datei mitsamt zugehörigem Beispielprogramm mal angesehen. Das Beispiel soll doch eine ein bestimmtes Verzeichnis rekursiv nach einer Datei durchsuchen können, oder?
Selbst hier funktioniert das nur, wenn die Datei im Startverzeichnis ist. Wurde die Funktion mal mit dem aktuellen FreePascal/Lazarus getestet?

Meine rekurisve Suchfunktion hatte nämlich gesten auch noch ohne Aufhängen funktioniert. Das Problem, mit den Links tauchte erst heute nach dem Update auf FP2.2 und L0.9.24 auf.

Guter Hinweis, es wird sicher noch unter FPC 2.0.4 und Laz 0.9.22 gewesen sein. Der Vorteil ist, der Entwickler liest mit

[Giantics]

faSymLink unterscheidet nur symbolische Links. Es gibt keine Möglichkeit HardLinks zu erkennen, weil alle Links auf einen Inode gleichwertig sind.

-Michael

Dann hab ich jetzt ein leider mehr oder weniger großes Problem. Gibts eine andere Möglichkeit herauszufinden, ob es sich dabei um einen Link handelt?

Was mich richtig wundert ist, dasss FPC2.0 und L0.9.22 die Links wohl noch gar nicht erkannt haben.

[Christian]

Sinn und zweck von Hardlinks ist das für Programme gerad nicht erkennbar ist das es Hardlinks sind. Es gibt aber API Funktionen mit denen man das abfangen kann musst mal die unix oder stdunix Funktionen durchgucken.

[theo]

Naia, die Frage ist warum du das umschiffen willst.
Wenn du einen Link hast, dann gehört das Verzeichnis ja eigentlich auch ausgegeben.
Was du machen könntest, wäre eine Liste mit allen abgegrasten Verzeichnissen halten um nicht zweimal in das selbe zu wandern.

Oder: Ich glaube Libc hat eine RealPath (o.ä.) Funktion. Damit kannst du checken, ob das Verzeichnis ausserhalb deines Root liegt.
Da musst du dich aber selber schlau machen.

Edit: @Christian: du warst schneller!

[Giantics]

Sinn und zweck von Hardlinks ist das für Programme gerad nicht erkennbar ist das es Hardlinks sind

Naja, irgendwie muss es gehen. "ls" erkennt die ja schließlich auch

Naia, die Frage ist warum du das umschiffen willst.
Wenn du einen Link hast, dann gehört das Verzeichnis ja eigentlich auch ausgegeben.
Was du machen könntest, wäre eine Liste mit allen abgegrasten Verzeichnissen halten um nicht zweimal in das selbe zu wandern.

Wenn ich der rekursiven Auflistung z.B. mein home Verzeichnis übergebe, dann ist darin das ".wine" Verzeichnis enthalten, das wiederum enthält mehere Hardlinks zu meinem home. Das bedeutet, dass ich in eine Endlosschleife gerate. Selbst wenn ich die Tiefe auf 10 Verzeichnisse begrenze, braucht er ewig und er listet die Dateien doppelt und 3-fach auf.
Das mit der Liste würde nur funktionieren, wenn der Original-Pfad und der Link-Pfad gleich wären, oder ("/home/user" ?=? "/home/user/.wine/windows/profiles/user")?

Oder: Ich glaube Libc hat eine RealPath (o.ä.) Funktion. Damit kannst du checken, ob das Verzeichnis ausserhalb deines Root liegt.
Da musst du dich aber selber schlau machen.

Das hört sich gut an. Dann werde ich mal in die Richtung recherchieren.

Danke euch allen.

[pluto]

wenn die Verzeichnisse alle mit . anfangen kannst du sie doch raus Filtern.
Wie fangen die Links den alle an, haben sie eine Erweiterung ?
Evlt. könntest du sie auch an der Datei Größe erkenne, ein Verzeichnis hat im allgemeinen Keine Größe, nur der Inhalt, darum müsste bei GetFileSize 0 bei Verzeichnissen rauß kommen bzw. bei sr.size wobei sr vom typ TSerachtyp sein sollte(oder so ählich...)

[Giantics]

Ich könnte natürlich die Verzeichnisse mit nem Punkt am Anfang rausfiltern (vielleicht ist das im Moment sogar noch die beste Lösung). Ich wollte halt flexibel bleiben. Schließlich kann es auch vorkommen, dass Links existieren, die in einem nicht versteckten Verzeichnis sind, oder dass Dateien mit aufgelistet werden sollen, die in versteckten Verzeichnissen sind.
Wie die Links aussehen, weiß man im Vorfeld natürlich nicht.

Das mit der Dateigröße ist noch ein guter Hinweis. Ich werd's mal testen. Danke!

Gruß
Thomas

[mschnell]

Gibts eine andere Möglichkeit herauszufinden, ob es sich dabei um einen Link handelt?

Die kann es nicht geben. Hardlinks sind keine Links im Sinne von Symlinks. Auf jeden Datei-Inhalt ("INode" genannt, kann auch ein Directory sein) kann es beliebig viele "Links" (=Einträge in Directories) geben. Der INode hat einen LinkCount, den man vermutlich auch mit einem API-call erfahren kann. Die Links sind aber absolut gleichwertig. Man kann im nachhinein nicht mehr herausfinden, welcher der erste Link war, der zu diesem INode existierte. Es muss ihn auch gar nicht mehr geben. Löschen einer Datei in Linux bedeutet, den Link auf den INode löschen (deshalb heißt es für Puristen auch "unlink" statt löschen). Wenn kein Link mehr auf einen Inode existiert, wird der INode selbst gelöscht.

-Michael

[creed steiger]

Du könntest die Inodes prüfen ob sie gleich sind

http://www.linux-praxis.de/lpic1/lpi101/1.104.7.html" onclick="window.open(this.href);return false;

http://community.freepascal.org:10000/d ... fstat.html" onclick="window.open(this.href);return false;