Findfirst / Findnext liefert falsche Ergebnisse

[Anthauri]

Hallo Delphianer,

ich bin auf folgendes Phänomen gestoßen.


Ich habe eine simple Findfirst / Findnext-Funktion um Dateien zu finden und in einer Listbox anzuzeigen. Hierbei kann der Anwender in ein Editfeld die Daten für den Filter der Suchfunktion eingeben.


In dem aktuellen Verzeichnis sind z.B. zwei Dateien mit den Namen:

"R 12.txt" und "R12.txt", dann findet der Aufruf beide Dateien obwohl als Filter "R12*" vorgegeben wurde. Das Space in dem einen Namen wird ignoriert.

Dann gibt es eine andere Datei mit dem Namen "abc.fgt.ghz.gt.txt" die ebenfalls gefunden wird, wenn der Filterinhalt "abc*1*" ist obwohl das Zeichen "1" überhauptnicht vorkommt. Mit "abc*2*" geht's aber nicht.


Irgendwie komisch dachte ich mir und bemühte den Windows Dateiexplorer mit gleichen Suchkriterien... Siehe da, auch der fand die eigentlich falschen Einträge... scheint also vom Betriebssystem abzuhängen (taucht im übrigen unter Win 98 und Win XP auf).


Hat jemand eine Idee, wie sich das korrigeieren läßt????

Derzeit plane ich (für meine eigentliche Anwendung) die Findnext-Funtkion alles finden zu lassen und die Ergebnisse dann über eine eigene Routine weiterzugeben oder zu ignorieren (also ein selbsterstellter Filter)
Aber eigentlich kann es das ja nicht sein, oder?

-----------------------------------------
Hier das (für den Test minimierte) Coding


var
__findfirsttest_f: Tfindfirsttest_f;
__srec : tsearchrec;

implementation

{$R *.dfm}

procedure Tfindfirsttest_f.b_reloadClick(Sender: TObject);
begin
_lb_result.Items.Clear;
_if findfirst(e_filter.Text,0,srec)=0
___then
_____try
_______repeat
_________lb_result.Items.Append(srec.Name);
_______until findnext(srec)<>0;
_____finally
_______findclose(srec);
___end;
end;
-----------------------------------------

P.S. die Unterstriche zu Beginn der Zeilen sind im Coding natürlich eigentlich nicht enthalten.
Ggf kann mir jemand erklären wie denn führende Leerzeichen mit in die Vorschau übernommen werden. Meine Experimente schlugen fehl. Daher die Notlösung mit den Unterstrichen zu Beginn, die eigentlich Spaces sind.

[Luckie]

Zitat von Anthauri:

P.S. die Unterstriche zu Beginn der Zeilen sind im Coding natürlich eigentlich nicht enthalten.

Und genau deswegen haben wir die [ delphi]-Tags.

[Snoop007]

FindFirst greift auf FindFirstFile aus der WinApi zurück daher die gleichen "Fehler"

[MathiasSimmack]

Zitat von Anthauri:

Dann gibt es eine andere Datei mit dem Namen "abc.fgt.ghz.gt.txt" die ebenfalls gefunden wird, wenn der Filterinhalt "abc*1*" ist obwohl das Zeichen "1" überhauptnicht vorkommt. Mit "abc*2*" geht's aber nicht.

Erinnert mich an die Geschichte mit den kurzen und langen Dateinamen. Unter 98 wird aus "abs.fgt.ghz.gt.txt" "absfgt~1.txt", weil 9x die langen Einträge quasi nur simuliert. Die Datei besitzt in der FAT eigentlich den 8.3-Namen (altes DOS-Relikt), aber zusätzlich gibt es noch einen Eintrag mit dem langen Namen.

[Anthauri]

Vielen Dank für die schnellen Antworten

Das mit den Tags kannte ich nicht, werde ich zukünftig aber nutzen.

Der Hinweis mit den alten DOS Namen ist tatsächlich die Lösung (auch unter XP).

Ich habe eine weitere Datei erstellt, die in den ersten Zeichen dem Namen der alten gleich ist
(abc.fgt.ghz.gz.txt) und diese wird gefunden, wenn als Filterwert "abc*2*" vorgegeben wird.
Die Suche bezieht sich also immer auf beide Namen (alt und neu).


Sachen gibt's....

[MathiasSimmack]

Na ja, dann nennen wir es nicht "Fehler" sondern "nostalgisches Problem"

[woki]

Zitat von MathiasSimmack:

Na ja, dann nennen wir es nicht "Fehler" sondern "nostalgisches Problem"

Nun ja, man muß ja nicht aus jedem Bug gleich ein Feature machen, nur weil Microsoft das Problem nicht interessiert, obwóhl (behaupte ich einfach Intuitiv aus meiner Erfahrung) jeder andere renommierte Betriebsssystemhersteller das im Griff hat. Weiterhin ist dieses unerwartete Verhalten nicht in der Standardwindowshilfe beschrieben, und deshalb ist und bleibt es ein Bug.