Dateien, Unterverzeichnisse zählen?

[Mattze]

Hallo,

ich trau mich ja schon fast nicht...

Wie zähle ich günstig ALLE Dateien und Unterverzeichnisse eines Verzeichnisses?
(ALLE meint wirklich alle, also auch die Dateien, die in den Unterverzeichnissen liegen bzw. auch die Unterverzeichnisse von Unterverzeichnissen...)

Ich habe das bisher mit einer rekursiven Funktion gemacht und das geht auch sehr gut. Nur in dem neuen Programm stürzt er mit einer Zugriffsschutzverletzung ganz woanders ab. (In einer völlig fremden Unit, die damit vordergründig gar nichts zu tun hat!)

Vielleicht gibt es da noch eine direktere Möglichkeit?

Gruß
Mattze

[DeddyH]

Zeig doch mal die rekursive Funktion, damit würde ich das nämlich auch machen.

[himitsu]

'ne andere Möglichkeit, als die Verzeichnisse rekursiv durchzugehn gibt es doch eigentlich nicht?

Aber ich kann mir nicht vorstellen, wieso soeine Funktion das Programm zum Abstürzen bringen sollte.
Vielleicht solltes du anstatt nach 'ner anderen Möglichkeit zu suchen lieber mal suchen warum der Fehler an der anderen stelle auftritt und diesen Fehler dann beheben.

Das Schnellste und Resourcenschonenste sollte wohl eine Funktion direkt auf Basis der WinAPI sein.
(Die Delphi-Funktionen ala FindFirst machen intern ja noch mehr, da sie ja darauf ausgelegt sind mit einer Maske zu suchen und zu filtern)

[Fridolin Walther]

Zitat von himitsu:

'ne andere Möglichkeit, als die Verzeichnisse rekursiv durchzugehn gibt es doch eigentlich nicht?

Eigentlich kann alles was in einer rekursiven Funktion gelöst wird, auch in einer nicht-rekursiven Funktion gelöst werden. Im Falle von Verzeichnisenumerierung ist es sogar sinnvoll.

Zitat von himitsu:

Aber ich kann mir nicht vorstellen, wieso soeine Funktion das Programm zum Abstürzen bringen sollte.

Der Stack ist nicht unendlich groß. Je nachdem wir hoch die Rekursionstiefe ist, kanns dann schon mal krachen.

Zitat von himitsu:

(Die Delphi-Funktionen ala FindFirst machen intern ja noch mehr, da sie ja darauf ausgelegt sind mit einer Maske zu suchen und zu filtern)

Der Filter wird eigentlich eins zu eins an die Windows API übergeben. Der einzige Overhead der entsteht besteht darin, das die Informationen aus der Windows Datenstruktur in die Delphi Datenstruktur kopiert werden.

[himitsu]

Zitat von 0xF30FC7:

Der Filter wird eigentlich eins zu eins an die Windows API übergeben. Der einzige Overhead der entsteht besteht darin, das die Informationen aus der Windows Datenstruktur in die Delphi Datenstruktur kopiert werden.

also bis D2006 war das noch nicht der Fall und ich kann mir nicht vorstellen, daß die es jetzt noch geändert haben.

Zitat:

Der Stack ist nicht unendlich groß. Je nachdem wir hoch die Rekursionstiefe ist, kanns dann schon mal krachen.

die Verzeichnistiefe ist auch nicht unendlich Groß, also wird es wohl nicht so leicht zum Crash kommen

Zitat:

Eigentlich kann alles was in einer rekursiven Funktion gelöst wird, auch in einer nicht-rekursiven Funktion gelöst werden. Im Falle von Verzeichnisenumerierung ist es sogar sinnvoll.

nur daß es eigentlich nahezu überall rekursiv gelöst wird (nja, so ist es halt auch noch irgendwie einfacher)

[Mattze]

Hallo,

meine Quelle sieht so aus:

Delphi-Quellcode:

type FG = array[0..2] of int64;  //Global definiert
     {0 - Größe, 1 - Anzahl Dateien, 2 - Anzahl unterverzeichnisse}

var FGAbbruch: Boolean = false;  //Global definiert

function GetFolderSize(const FolderName: string): FG;
var   FN: string;
      ex: fg;
      sr: Tsearchrec;
begin
   result[0]:=0; result[1]:=0; result[2]:=0;
   if FgAbbruch then exit;
   FN:=foldername;
   er:=findfirst(FN+'\*.*',faanyfile,sr);
   while er=0 do begin
      if fgabbruch then begin
        result[0]:=0; result[1]:=0; result[2]:=0;
        break;
      end;
      application.processmessages;
      if (sr.attr and fadirectory = fadirectory) then begin
         if (sr.name<>'..') and (sr.name<>'.') then begin
            inc(result[2]);
            ex:=getfoldersize(fn+'\'+sr.name);
            result[0]:=result[0]+ex[0];
            result[1]:=result[1]+ex[1];
            result[2]:=result[2]+ex[2];
         end
      end else begin
         inc(result[1]);
         result[0]:=result[0]+sr.size;
      end;
      er:=findnext(sr)
   end;
   sysutils.findclose(sr);
end;

Bei der Fremdunit, bei der ein Fehler auftritt, handelt es sich um EasyListview. Da ist es nicht so einfach möglich, alles zu ändern. (Zumal der Fehler an einer sehr wichtigen Stelle auftritt!)

Ich habe es auch mal versucht, das nichtrekursiv zu machen, weil ich eben auch mal gelesen habe, dass man alles rekursive auch nicht rekursiv machen kann. Ich bin da nicht weit gekommen, hab's einfach nicht hingekriegt.
Wie macht man das?

Gruß
Mattze

[Fridolin Walther]

Zitat von himitsu:

Zitat von 0xF30FC7:

Der Filter wird eigentlich eins zu eins an die Windows API übergeben. Der einzige Overhead der entsteht besteht darin, das die Informationen aus der Windows Datenstruktur in die Delphi Datenstruktur kopiert werden.

also bis D2006 war das noch nicht der Fall und ich kann mir nicht vorstellen, daß die es jetzt noch geändert haben.

Delphi 2007:

Delphi-Quellcode:

function FindMatchingFile(var F: TSearchRec): Integer;
var
  LocalFileTime: TFileTime;
begin
  with F do
  begin
    while FindData.dwFileAttributes and ExcludeAttr <> 0 do
      if not FindNextFile(FindHandle, FindData) then
      begin
        Result := GetLastError;
        Exit;
      end;
    FileTimeToLocalFileTime(FindData.ftLastWriteTime, LocalFileTime);
    FileTimeToDosDateTime(LocalFileTime, LongRec(Time).Hi,
      LongRec(Time).Lo);
    Size := FindData.nFileSizeLow or Int64(FindData.nFileSizeHigh) shl 32;
    Attr := FindData.dwFileAttributes;
    Name := FindData.cFileName;
  end;
  Result := 0;
end;

function FindFirst(const Path: string; Attr: Integer;
  var  F: TSearchRec): Integer;
const
  faSpecial = faHidden or faSysFile or faDirectory;
begin
  F.ExcludeAttr := not Attr and faSpecial;
  F.FindHandle := FindFirstFile(PChar(Path), F.FindData);
  if F.FindHandle <> INVALID_HANDLE_VALUE then
  begin
    Result := FindMatchingFile(F);
    if Result <> 0 then FindClose(F);
  end else
    Result := GetLastError;
end;

FindMatchingFile führt zwar Filterung durch auf Grund der angegebenen Attribute, aber der Vergleich bzw. die Bitweisen Operationen kaum ins Gewicht. Die von Dir angesprochene "Maske" wird 1 zu 1 an Windows übergeben.

Zitat von himitsu:

die Verzeichnistiefe ist auch nicht unendlich Groß, also wird es wohl nicht so leicht zum Crash kommen

Das kommt darauf an, wie die Systemsettings aussehen. Wie groß ist der Stack z.B. letztlich bzw. was ist angefordert. Dann kommt es darauf an ob und was für lokale Variablen auf dem Stack liegen. So ein Stacklimit überschreitet man bei Rekursion schneller als man denkt. Die maximale Pfadlänge beträgt bei NTFS 32767 Zeichen. Bedeutet Rekursionstiefen von 10000+ sind problemlos machbar (Pfad: \\.\C:\A\A\A\A\A\...). Wenn Du dann bei jeder Funktion n 50 kb Array auf dem Stack liegen hast, krachts.

Zitat von himitsu:

nur daß es eigentlich nahezu überall rekursiv gelöst wird (nja, so ist es halt auch noch irgendwie einfacher)

Nur weil andere es auch falsch machen, wirds dadurch nicht besser ...

[himitsu]

Zitat:

Pfad: \\.\C:\A\A\A\A\A\...

Aber mal ganz im Ernst, wie oft kommt sowas vor?

Die 32767 Zeichen kommen nur in Verbindung mit UNC-Pfadnamen vor ... ansonsten ist bei 259 Zeichen Schluß. (MAX_PATH - die letzte #0)
Und ich glaub kaum, daß er in seinem Programm UNC verwendet.

[SirThornberry]

Ganz unberichtigt ist die Aussage das der Stack nicht unendlich groß ist nicht. Denn man kann unter anderem bei NTFS in einen Ordner eine Partition einhängen/mounten. Hat man also das Laufwerk C und drauf den Ordner A kann man in Ordner A durchaus auch wieder die Partition von Laufwerk C einhängen. Daraus resultiert eine unendliche Pfadtiefe. So etwas sollte man eventuell auch berücksichtigen. Eventuell durch festlegen einer maximalen Pfadtiefe um keine Endlosrekursion zu haben.

[Fridolin Walther]

Zitat von himitsu:

Zitat:

Pfad: \\.\C:\A\A\A\A\A\...

Aber mal ganz im Ernst, wie oft kommt sowas vor?

Die 32767 Zeichen kommen nur in Verbindung mit UNC-Pfadnamen vor ... ansonsten ist bei 259 Zeichen Schluß. (MAX_PATH - die letzte #0)
Und ich glaub kaum, daß er in seinem Programm UNC verwendet.

Da wäre eine Rekursionstiefe von 125+ möglich. Das reicht mitunter für nen Crash. Kommt auf die lokalen Variablen an und wie groß der Stack werden darf.

Aber ansonsten ordne ich solche Aussagen wie "Das kommt so selten vor" immer in die "Famous last words" Kategorie ein . Ist nicht bös gemeint, aber ich erinner mich da immer an eine lustige Unterhaltung nach nem Code Audit. Zitat Entwickler: "Da würde doch niemals jemand auf die Idee kommen dort mehr als 255 Zeichen für einen Usernamen zu verwenden." Zwei Monate später gabs dann nen Exploit auf milw0rm.

Aber um wieder OnTopic zu werden:
An der Routine selbst ist nichts auszusetzen, ausser halt das der Stack ausgehen kann (was aber eher unwahrscheinlich ist, ich gebs ja zu). Hast Du aus der Funktion evtl. was rausgekürzt? Evtl. Zugriffe auf das Treeview bei dem es dann crashed? In welchem Kontext wird die Funktion ausgeführt? Aus dem Hauptthread heraus? Rennts in nem extra Thread? Wie lautet die exakte Fehlermeldung?