findFirst systemabhängig??

[hackyie]

hi,

hier mal meine findFirst-Methode, ich möchte ausschließlich Ordner suchen und die Ordner [.] und [..] ausschließen:

Delphi-Quellcode:

if FindFirst(apPath + 'discs\*.*', faDirectory, SearchRec) = 0 then
  begin
    repeat
      if pos('.',SearchRec.Name) = 0 then
        ListBox1.items.add(searchrec.Name);
    until FindNext(searchrec) <> 0;
    findclose(searchrec);
  end;

Das ganze funktioniert auf meinem Win XP prof. System hundertpro, alle Ordner landen in der Liste. Auf dem System meines Vaters (auch Win XP prof) findet er null Ordner obwohl er 100% im richtigen Verzeichnis sucht und dort auch die Ordner existieren. Sind auch nicht versteckt oder ähnliches, ich kann das komplette Verzeichnis von emienm Rechner auf seinen kopieren und dort läuft es nicht mehr. warum?

Und am Rande: gibt es ne Möglichkeit, findFirst nur nach Ordnern suchen zu lassen und die nicht so umständlich rauszufiltern wie ich das gemacht habe?

Danke schonmal :)

[Martin K]

Ein Ordner kann auch einen Punkt im Namen enthalten!

Mein Vorschlag:

Delphi-Quellcode:

  if FindFirst('*', faAnyFile, SR) = 0 then
  try
    repeat
      if (SR.Attr and faDirectory <> 0) and (SR.Name <> '.') and (SR.Name <> '..') then
        // SR.Name ist ein Ordner!
    until FindNext(SR) <> 0;
  finally
    FindClose(SR);
  end;

//Edit:
*.* durch * ersetzt.

[hackyie]

klasse, das läuft schonmal. Aber ich glaube nicht, dass das an der System-Inkompatibilität was ändert, mal testen nachher...

[Neutral General]

Du kannst nur Ordner suchen wenn du als Parameter bei FindFirst statt faAnyFile faDirectory angibst ;)

Gruß
Neutral General

[Martin K]

Zitat:

Zitat von Neutral General

Du kannst nur Ordner suchen wenn du als Parameter bei FindFirst statt faAnyFile faDirectory angibst ;)

Gruß
Neutral General

Hast Du es mal ausprobiert?
Bei mir ändert es nichts daran, ob ich nach faAnyFile oder nach faDirectory suche.
Beidemale wird nach Dateien und Ordnern gesucht.
Erst die Überprüfung SR.Attr and faDirectory<>0 sagt mir, ob es Datei oder Ordner ist.

Im Übrigen:
Nur nach Dateien suchen geht so:
faAnyFile-faDirectory bei FindFirst als Parameter.

Für die Suche nur nach Ordnern gibt es imho dort keine Parameter...

[hackyie]

korrekt. denn der Parameter gibt ja an, was zusätzlich zu anyFile gesucht werden soll. VOn daher glaube ich auch nicht, dass man schon direkt in FIndfirst alle Dateien ausschließen kann...

edit: heissa, es läuft auf beiden Systemen! so gravierend hab ich an sich gar nichts geändert, aber es läuft. Strange.

[jbg]

Zitat:

Zitat von Martin K

faAnyFile-faDirectory

+ und - sind nicht für Bit-Operationen gedacht, sondern zum addieren undd subtrahieren. Für Bit-Operationen sollte man or (Bit setzen) bzw. and not (Bit löschen) benutzen. Auch wenn es mehr schreibarbeit ist, es ist richtiger und führt nicht zu schwer auffindbaren Fehlern. Was wenn mal faDirectory nicht in faAnyFile enthalten ist, weil irgendein Schlauberger sich faAnyFile umdefiniert hat, damit es seinem Namen gerecht wird. Subtrahiert er nun faDirectory, so löscht er das Bit unterhalb von faDirectory, war er gar nicht wollte.

[negaH]

OT: Martins vorgeschlagener Source ist perfekt, danke !

Gruß Hagen

[SirThornberry]

Was mir auffällt: Du suchst nach "*.*". Streng genommen suchst du also nach Ordnern welche mindestens einen "." im Namen haben. Wenn du nach "*,*" suchst erwartest du ja auch das nur dinge gefunden werden wo "," drin vorkommt. Bei "." scheint das auf manchen Systemen eine Ausnahme zu sein. Aber Generell sollte man nur nach "*" suchen wenn man wirklich alle Namen finden will.

[Martin K]

Zitat:

Zitat von SirThornberry

Was mir auffällt: Du suchst nach "*.*". Streng genommen suchst du also nach Ordnern welche mindestens einen "." im Namen haben. Wenn du nach "*,*" suchst erwartest du ja auch das nur dinge gefunden werden wo "," drin vorkommt. Bei "." scheint das auf manchen Systemen eine Ausnahme zu sein. Aber Generell sollte man nur nach "*" suchen wenn man wirklich alle Namen finden will.

Stimmt.
Aber bei Windows ist wohl *.* = *
Ich verbessere es lieber mal im obigen Code, damit's keine Probleme gibt, wenn ihn jemand mal einfach so auf die Schnelle kopiert...

[negaH]

*.* ist absolut richtig gewesen. Ein * für den Dateinamen, ein Komma . zur Trennung zur Extension, und ein * für die Extenstion/Erweiterung einer Datei.

Gruß Hagen

[Martin K]

Zitat:

Zitat von negaH

*.* ist absolut richtig gewesen. Ein * für den Dateinamen, ein Komma . zur Trennung zur Extension, und ein * für die Extenstion/Erweiterung einer Datei.

Gruß Hagen

Ja, aber hier geht es doch um Ordner :shock: , nicht um Dateinamen.
Theoretisch dürfte er dann nur nach Ordnern suchen, die einen . Punkt im Namen enthalten.
Aber praktisch erhält man so trotzdem alle Ordner...

[negaH]

Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Ich sagte ja schon das dein ehemaliger Source absolut sauber und perfekt ist, dh. eine Suchschleife für FindFirst(), FindNext() und FindClose() sollte exakt so aufgebaut sein wie dein Source.

1.) FindClose() in try finally
2.) FindClose() nur dann wenn FindFirst() was findet -> wichtig! für ältere Delphi RTLs
3.) die Abfrage auf Directory zuerst Attr per and auswerten, danach SR.Name <> '.' und danach erst SR.Name <> '..' das erzeugt den effizientesten Code, diese Reihenfolge der Auswertung ist also entscheidend und so wie du das gemacht hast ist es am effizientesten.

Sehr oft sieht man Auswertungen wie SR.Name[1] <> '.' oder Pos('.', SR.Name) > 0, diese sind jedoch defakto falsch. Odner könnten auch ".Name" oder "Name.Name" benannt sein. Oder man sieht sowas wie SR.Attr <> faDirectory was ebenfalls falsch ist. Denn damit würde man Directories mit Attr = faDirectory or faHidden, also versteckte Ordner eben nicht ausfiltern. Auch sehr oft zu sehen SR.Attr < 0, das geht weil faDirectory glaube ich das Signbit darstellt, ist aber denoch falsch da diese Auswertung vom Datentyp SR.Attr abhängig ist. Sollte dies ein Word/Cardinal sein so wäre SR.Attr < 0 ebenfalls absolut falsch. Wie gesagt, so wie du das gemacht hast ist es die beste Lösung.


Gruß Hagen

[Martin K]

Also erstmal Danke für Deine Komplimente, aber ich habe den Code mir irgendwann auch mal aus versch. Beiträgen hier im Forum zusammengebastelt.

Zitat:

Zitat von negaH

Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.
Es gibt sogar Dateien, die keine haben
:arrow: also kein . im Dateinamen / Ordnernamen!
Wieso deshalb nach einem . suchen?
Aber dazu hat ja SirThornberry schon was geschrieben...

Zitat:

Zitat von negaH

Sehr oft sieht man Auswertungen wie SR.Name[1] <> '.' oder Pos('.', SR.Name) > 0, diese sind jedoch defakto falsch. Odner könnten auch ".Name" oder "Name.Name" benannt sein.

Genau wie hier (erster Beitrag):

Zitat:

Zitat von hackyie

Delphi-Quellcode:

if pos('.',SearchRec.Name) = 0 then

Deshalt schrieb ich ja auch:

Zitat:

Zitat von Martin K

Ein Ordner kann auch einen Punkt im Namen enthalten!

:wink:

[sakura]

Zitat:

Zitat von Martin K

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.

Oh, da merkt man wie alt man ist :mrgreen: Windows unterstütz auch heute noch das 8.3 Namesprinzip, FindFirst & Co. auch und im 8.3 System hatte jede Datei und jeder Ordner 8 Zeichen für den Namen und 3 für die Erweiterung. Fakt ist jedoch, dass gerade bei Ordner meistens auf eine Angabe für die Erweiterung verzichtet wurde.

Wenn eine Datei bzw. ein Ordner nicht alle 8 bzw. 3 Zeichen genutzt hatte, so hat das OS die betreffenden Stellen in der FAT mit #32 aufgefüllt und "unterstützte" somit auch Datei-/Ordnernamen mit weniger als 8 Zeichen vorn bzw. 3 hinten.

Zitat:

Zitat von Martin K

Es gibt sogar Dateien, die keine haben

So gibt es auch Ordner die eine Erweiterung haben ;)

Zitat:

Zitat von Martin K

:arrow: also kein . im Dateinamen / Ordnernamen!

Die Suche von FindNext findet auch Dateien/Ordner ohne Erweiterung, wenn man nach *.* sucht, da dieses die feste Maske für alles ist. Egal ob mit oder ohne Erweiterung.

...:cat:...

[Martin K]

Zitat:

Zitat von sakura

Die Suche von FindNext findet auch Dateien/Ordner ohne Erweiterung, wenn man nach *.* sucht, da dieses die feste Maske für alles ist. Egal ob mit oder ohne Erweiterung.

Trotzdem ist es irgnedwie logischer, nur nach * zu suchen, v.a. wenn es sich um Ordner handelt.
...außerdem ist es weniger Schreibarbeit und die pas wird 2 Byte kleiner :zwinker:

Mir ist allerdings nicht klar, was Ordner für Extensions haben könnten...
Hab grad in meinem Windows-Verzeichnis einen Ordner gefunden, der Microsoft.NET heißt.
Aber ist deswegen jetzt die Extension .NET ???

[fwsp]

es gibt doch das märchen, dass ordner die endung ".dir" hätten...

[sakura]

Zitat:

Zitat von fwsp

es gibt doch das märchen, dass ordner die endung ".dir" hätten...

Es ist halt ein Märchen ;)

...:cat:...

[sakura]

Zitat:

Zitat von Martin K

Mir ist allerdings nicht klar, was Ordner für Extensions haben könnten...
Hab grad in meinem Windows-Verzeichnis einen Ordner gefunden, der Microsoft.NET heißt.
Aber ist deswegen jetzt die Extension .NET ???

Wie auch bei Dateien, wird nach der 8.3 Konvention wie folgend für die Extension vorgegangen: die ersten drei legalen Zeichen nach dem letzten Punkt werden zur Extension. Also wird aus dem Ordner Microsoft.NET sehr wahrscheinlich MICROS~1.NET, wobei "~1" auch andere Werte annehmen kann, um Namenskollisionen zu vermeiden.

...:cat:...

[negaH]

Zitat:

Zitat:

negaH hat folgendes geschrieben:
Die Trennung eines Dateinamens, egal ob Datei oder Ordner, ist immer Name.Extension

Das kann ich nicht so stehen lassen, da ein Ordner keine Extension hat.

Du musst es so stehen lassen, weil es richtig ist. Ein Ordner kann eine Extension besitzen, punkt.

Öffne die Eingabeaufforderung->DOS Box und geben ein "md Test.XYZ" und schaue dir im Explorer den erzeugten Ornder an. Nun suchst du mit deinem Source -> FindFirst('*.XYZ', faDirectory, SR) und wirst diesen Ordner auch finden.

Gruß Hagen

[Martin K]

Na gut, überzeugt.
Aber bei Dateien bestimmt die Erweiterung ja den Typ:
.jpg -> JPEG-Bild
.mp3 -> Musik im MP3-Format

Aber was sagt eine Erweiterung bei einem Ordner aus ? :gruebel:
-> Gar nichts!
Der Typ ist und bleibt "Dateiordner".

Deshalb würde ich es nicht Erweiterung nennen, sondern eben ein Teil des Ordnernamens.
(Okay, bei Dateien ist die Erweiterung auch ein Teil des Dateinamens...)

[negaH]

@Martin:

du machst da einen Fehler. Das alles ist reine Definitionssache, eine übrigens sehr alte Definitionssache aus DOS Zeiten und gemacht von Microsoft. Das heist, es hat nichts mit erklärbarer oder nachvollziehbarer Logik zu tuen.

Und per Definition:

Ein FAT Eintrag hat einen Namen und eine Extension. Ob ein Eintrag ein Ordner, eine Datei oder ein VolumeLabel ist definitiert sich ausschleißlich nur über die Attribute dieses FAT Eintrages und nicht über dessen Namen.

Ein Ordner oder VolumeID kann also eine Extension besitzen, ob das logisch ist oder irgendeinen Sinn ergeben muß sei dahingestellt, da es einfach technisch so umgesetzt wurde.

[edit]
Entscheidend für uns ist nur folgendes:

1.) es ist unsere Umwelt in der wir uns als Programmierer bewegen
2.) diese Umwelt haben andere ausgedacht
3.) sie muß nicht zwangsläufig immer logisch sein
4.) diese Umwelt ist über Jahre gewachsen, modernisert worden und hat noch einiges an altem Ballast, das erzeugt unlogische Dinge
5.) es ist nur allzu effizient als Programmierer diese Gegebenheiten erstmal hinzunehmen sie als neues Wissen zu speichern, statt viel Zeit darin zu vergeuden sie mit irendeiner Logik erklären zu wollen


Übrigens wurde zu DOS und Win3.1 Zeiten die Möglichkeit einen Ordner mit einer Extension zu versehen aktiv mißbraucht um Ordner unlöschbar zu machen. Denn unter früheren OS streikte das API bei solchen Ordnern, aber nur bei einigen API Funktionen, andere Funktion arbeiteten aber einwandfrei mit solchen Ordnern.

[/edit]

Gruß Hagen

[Martin K]

Na, dann:
Danke für die Aufklärung!

Aber das alles ändert nix dran, ob es besser ist nach * oder nach *.* zu suchen.
Bei beidem kommt dasselbe raus. :wink: