Ordnergröße mit DirectoryEntrySize() ergibt immer nur 0

[OlderCoder]

Hallo miteinander,

ich habe mal wieder ein ganz einfaches Problem, an dem ich aber scheitere.
Bei einem Programm-Projekt brauche ich die Speichergröße von Ordnern.
Die einzige Funktion, die ich dafür gefunden habe ist DirectoryEntrySize().
Hier im Forum gab es noch GetDirectorySize(), aber der Thread ist 10 Jahre alt und die Funktion offensichtlich nicht mehr verfügbar.

Leider funktioniert das bei mir nicht. Ich bekomme als Ordnergröße immer nur den Wert 0
Ich habe versucht, das Problem auf das Minimum zu reduzieren, um es einzugrenzen, was aber auch nicht hilft:

Code: Alles auswählen

   If ExamineDirectory(0, "D:\test","*")  ; Programmpfad öffnen
      While NextDirectoryEntry(0)          ; Eintrag im Ordner holen
        Debug DirectoryEntryName(0) 
        Debug DirectoryEntrySize(0)
      Wend  
    Else                                                ; falls der Pfad nicht zu öffnen war
      Debug "Pfad war nicht zu öffnen!"
    EndIf  

In dem Ordner test befindet sich ein weiterer Ordner mit einigen Dateien und laut Windows mit einer Größe von 224MB.
Das Programm gibt den korrekten Ordnernahmen aus, aber als Größe nur 0.
Was mache ich falsch?
Die PureBasic-Hilfe ist mir in diesem Fall keine, und auch das Internet hat für mich keine Antwort. Deshalb hoffe ich auf Eure Hilfe.

Danke fürs Lesen.

LG OlderCoder

[Olafmagne]

Hallo,

Dein Code ergibt bei mir ein korrektes Ergebniss.
(getestet mit einem Ordner mit 2 .png-Dataien)

Olaf

[Bisonte]

Du musst das ganze rekursiv machen...
Ein Verzeichnis im Verzeichnis wird nicht ausgelesen...

Du muss das gesamte verzeichnis einlesen und die Dateigrössen addieren ... Ein Verzeichnis hat immer die Grösse 0.

[OlderCoder]

Guter Gott, hab ich das richtig verstanden?
Diese Funktion ermittelt gar nicht, wie von mir angenommen, den gesamten Speicherbedarf (natürlich auch inklusive Unterordnern, wie ich bequemerweise erwartet hatte), sondern nur den von einzelnen Dateien, die sich in diesem Ordner in oberster Ebene befinden?
Das erklärt natürlich das Ergebnis. Und ich muss jetzt auch noch erkennen, ob es sich bei dem nächsten Eintrag um eine Datei handelt oder einen Ordner, und im letzteren Fall weiter in die Tiefe gehen?
Das ist enttäuschend - aber nicht zu ändern. Aber damit hatte ich gar nicht gerechnet.
Ich dachte, PureBasic ist so mächtig, hat sicher auch diese Funktion an Bord. Das wundert mich direkt. Windows kann es doch auch.
Ich habe mal kurz sämtliche Dateien im innenliegenden Ordner in den darüberliegenden geräumt, und das Ergebnis bestätigt das.
Ich hatte früher sowas schon mal programmiert für ein Suchprogramm, aber jetzt nicht mit so einem Aufwand gerechnet. Da muss ich wohl mehr Zeit einplanen.
Um rekursiv hatte ich immer einen Bogen gemacht, da hab ich schnell einen Knoten ins Denken bekommen. Ich hab dann mit Feldern und Zeigern gearbeitet und kam auch zum Ziel. Ich muss mir das mal anschauen, was ich damals so gemacht hatte.
Vielleicht hatte ich aber sogar letztlich rekursiv programmiert, ohne mir dessen bewusst zu sein. Alles möglich, wenn man keinen Durchblick hat
Aber kann man nicht irgendwie über eine Windows-API-Funktion das ganze vereinfachen? Irgendwo muss das doch stecken.
(Aber Ihr seid natürlich so geschickt und habt blitzartig einen kompakten PB-Code gezaubert, der das kann. Ich sicher nicht.)

Vielen lieben Dank! Hier wird einem auf jedem Fall geholfen
LG OlderCoder

Edit: Ich schau mir das hier viewtopic.php?t=28832 mal an. Vielleicht versteh ich es ja so weit, dass ich nicht nur eine Black-Box in meinen Code versuchen muss einzuarbeiten. Das wäre mir deutlich lieber.
Halt nein, das war ja mit dem veraltetem Befehl. Aber vielleicht hilft mir das trotzdem.
Edit vom Edit: Ich hab mal wieder nur Bahnhof verstanden . Der vermeintlich alte ungültige PB-Befehl ist nur eine Prozedur.

[HeX0R]

Also bei mir zeigt Windows (also der Explorer) keine Größe von Verzeichnissen an.
Erst wenn ich auf Eigenschaften gehe, und dann fängt Windows auch an zu rödeln, um die Gesamtgröße herauszufinden.

[OlderCoder]

Aber genau das meine ich. Windows kann grundsätzlich die Größe von Ordnern ermitteln. Wenn auch nicht als Detailangabe für den Explorer.
Könnte ja sein, dass diese Fähigkeit auch in der API irgendwo verfügbar ist.
Andererseits kann ein PB-Code im Optimalfall vielleicht schneller sein als Windows. Dieses Gerödel kenn ich auch nur zu gut.
Aber dieser Vorgang braucht eben seine Zeit. Alternative Dateimanager (wars der Total Commander...?), die das direkt anzeigen, brauchen dafür auch eine gewisse Zeit. In Echtzeit ist sowas nicht möglich.
Aber egal. Ich werde aus meinem alten Suchprogramm die Prozedur herausholen und vereinfachen. Damit hatte ich auch den Ordner-Speicherbedarf ermitteln lassen. Auch ein Haufen Arbeit, aber immer noch erfolgversprechender als dieses Rekursivzeugs bei mir. Das letztlich vermutlich sowieso sehr Ähnliches tut, wie ich das damals gemacht habe. Nur mit einem anderen Ansatz.
Wenn ich Zeit habe.

[Kiffi]

Hier mal eine Quick'n Dirty - Lösung:

Code: Alles auswählen

Define Path.s = "[HierDeinenPfadEintragen]"
Define Program

Program = RunProgram("cmd.exe", "/c dir " + Chr(34) + Path + Chr(34) + " /s", "", #PB_Program_Open | #PB_Program_Read | #PB_Program_Hide)
If Program
  While ProgramRunning(Program)
    If AvailableProgramOutput(Program)
      If FindString(ReadProgramString(Program), "Anzahl der angezeigten Dateien:") ; wenn Du ein anderssprachiges Windows hast, solltest Du dieses hier anpassen
        Debug Trim(ReadProgramString(Program))
      EndIf
    EndIf
  Wend
  CloseProgram(Program)
EndIf

P.S.: Eine eigene PB-Routine zum rekursiven Einlesen der Dateigrößen ist allerdings die bessere Wahl

[OlderCoder]

Vielen Dank! Dass das so einfach damit möglich ist...Es hat funktioniert und ist auch schnell genug.
Seltsam, wenn ich im cmd.exe-Fenster dasselbe direkt eingebe, bekomme ich nur die Fehlermeldung "Der Befehl "/c" ist entweder falsch geschrieben oder konnte nicht gefunden werden." /c scheint es dort gar nicht zu geben.
Was mich wieder mal daran hindert, das ganze komplett zu verstehen, was mich immer stört.
(Das kann sich auch negativ auswirken, falls es z.B. mal Probleme gibt und man etwas ändern muss.)
Aber so funktioniert es.
Ich wusste darüber früher mal Bescheid, aber das ist lange her.
Klar, elegant ist das nicht. Aber der Zweck heiligt die Mittel. Ich spare mir Zeit, die ich sonst nicht hätte.
Und es ist auf jedem Fall viel kürzer, als das selbst zu schreiben.
Wenn es nicht noch irgendeinen anderen Nachteil hat, verwende ich das so.
LG OlderCoder

[Kiffi]

In der cmd gibst Du den Befehl ohne /c ein.

Code: Alles auswählen

dir "DeinPfad" /s

Dann passiert ne ganze Menge auf dem Bildschirm. Uns interessiert aber nur die Zeile, die am Schluss der Ausgabe nach "Anzahl der angezeigten Dateien:" kommt.

[OlderCoder]

Ah ok. dir kenn ich. Aber warum fällt dann /c weg? (Ich komm mir vor wie ein kleines Kind ("und waruuuum?.....")
Eigentlich könnte man meinen, dass man dasselbe im cmd.exe-Fenster eingeben kann, was auch PureBasic an cmd.exe schickt.

Und mich würde noch interessieren, warum beim Auslesen eines Ordners mit NextDirectoryEntry() nicht nur Dateien und Ordner auftauchen, sondern am Anfang auch immer die Einträge \. und \.. .
Die filtere ich dann eben raus, aber es wär schon nett, zu wissen, warum das überhaupt passiert.
Erkennbar ist aber mit cmd.exe, dass \. sich auf den gesamten Ordner bezieht, und \.. auch noch weitere im übergeordneten Ordner liegende Einträge mit einbezieht. Das kann ja durchaus mal nützlich sein.
Nur die Logik dahinter, wenn man Einträge eines Ordners abruft, erschließt sich mir dabei nicht.