MDirStat ist eine Neuimplementation von WinDirStat, was wiederum eine Portierung von KDirStat ist.



Was tut es?
Wie auch seine Vorgänger zeigt MDirStat die Festplattenbelegung unter Verwendung von Treemaps an. Jeder Datei wird dabei eine Fläche in einer Zeichenfläche zugeordnet, durch die man große Dateien schnell erkennen kann.

Warum noch ein Projekt?
WinDirStat hat so seine Eigenheiten, die es für manche Fälle recht schwer benutzbar machen. Ausschlaggebend für mich war die eher mäßige Erkennung von Mountpunkten und Junctions, durch die es bei meinem System gerne mal kompletten Käse ausgerechnet hat. Es gibt zwar einen Fork, der das richtig macht (altWinDirStat), aber der hat dafür einige andere Macken.
Oh, und nebenbei ist MDirStat auffallend schneller, ohne dass ich dafür was getan hätte

Bedienung
Die angezeigte Dateigröße ist immer die reale Größe, die Windows als "Größe auf dem Datenträger" meldet, und kann damit in beide Richtungen vom erwarteten Wert abweichen.
Die Baum- und Treemap-Ansicht sind synchronisiert: ein Objekt in einem auswählen markiert das Objekt auch in dem anderen. Beide bieten das System-Kontextmenü zum jeweiligen Objekt an. Durch "File->Update Selection" kann der markierte Teilbaum aktualisiert werden, "Update All" aktualisert alles, "Open" öffnet den Zielauswahldialog.
In der Baumansicht werden komprimierte Dateien und Sparse Files blau markiert.
Die Farben werden aus dem Dateityp abgeleitet, so dass Dateien mit gleicher Erweiterung die gleiche Farbe bekommen.
Öffnet man ein Hauptverzeichnis (oder einen Mountpunkt), so werden zwei weitere Einträge eingefügt: Free Space (freier Platz, wie von Windows gemeldet) sowie Unknown (Differenz zwischen allem messbaren und dem, was nach Gesamtgröße-Frei belegt sein müsste). Sehr große Unknown-Blöcke können zum Beispiel durch Schattenkopien belegt werden, oder in geringerem Maß durch Fragmentierung entstehen (da Verzeichniseinträge nicht sauber messbar sind).
In den Optionen kann der Treemap-Stil sowie die Darstellung konfiguriert werden.

Installation
MDirStat muss nicht installiert werden. Ist eine Datei "ExeName.portable" im Programmverzeichnis vorhanden, so wird die Konfigurationsdatei im Programmverzeichnis abgelegt. Ansonsten wird ein Ordner in den Anwendungsdaten verwendet.

Quelltext
Der Quelltext ist im Git-Repository des Projektes verfügbar. Er steht unter der Apache-2.0-Lizenz.
Gebaut ist das ganze mit Lazarus 2.0 und FPC 3.3 (also Snapshot-Versionen), sollte aber problemlos auch mit 1.4 und 3.0 laufen. Es wird die mit Lazarus ausgelieferte Version von VirtualTreeView sowie bitSpaceUtils und bitSpaceControls verwendet.


Viele Grüße,
Martok

Zip-Datei lässt sich mit Standard-Windows-Bordmitteln nicht öffnen.
Vielleicht mal ein anderes Zip-Format hochladen.
Ich habe es mit WinRar öffnen können.

jasocul hat folgendes geschrieben :

Zip-Datei lässt sich mit Standard-Windows-Bordmitteln nicht öffnen.

Das lag daran, dass es keine Zip-Datei war. 7Zip war der Meinung, dass eine Dateiendung von "zip" ja noch kein Grund ist auch eine zip zu erstellen, und hat eine 7z erstellt

Moin,

coole Sache, so eine Treemap. Leider funktioniert die nur auf meinen Nicht-Windows Partitionen (oder nicht-SSD-Partitionen?). Auf der C:-Partition wird zwar eine TreeMap gerendert, jedoch entsteht ein großer Block Unknown mit negativem Inhalt und das Klicken in der Map funktioniert nicht mehr.



Gruß
Finn

Moin!

Ich nutze WinDirStat am Job relativ häufig, um den Überblick über unsere Storage-Systeme zu behalten (oder besser: was unsere User so damit tun ). Hab mir grade deinen Port angesehen und es ist tatsächlich deutlich schneller! Super, ich werd´s weiter testen. Vielen Dank!

Wenn ich noch eine kleine Anmerkung machen bzw. Wunsch äußern dürfte: kannst du den "Free Space"-Block in der TreeMap immer in Grau anzeigen (das macht WinDirStat auch), so dass man gleich sieht, dass das keine "Datei" ist? Ich bin sonst immer so erschrocken, was da für riesige Files rumliegen...

cu
Narses

Hey Klasse!

Ich benutze WinDirStat auch schon lange.

MDirStat scheint einerseits ein bisschen schneller als WinDirStat zu sein, z.B. beim Aufklappen von riesigen Verzeichnissen wie C:\Windows\WinSxS. Aber andererseits fühlt es sich ziemlich zäh an, wenn ich z.B. in der Listview per Tastatur navigiere (Pfeiltaste gedrückt halten, die rote Markierung des aktuellen Items in der Treemap wird aktualisiert, die Listview dagegen wird erst wieder neu gezeichnet wenn ich die Taste loslasse).

Das negative "Unknown"-Problem von FinnO kann ich bestätigen. Passiert bei mir nur, wenn ich MDirStat als Admin starte. Mit normalen rechten bekomme ich immer noch einen Unknown-Block, dann aber mit 2,4 GB statt negativ.

Kleiner Feature-Request: die Anzeige des freien Speichers als eigenen Block würde ich gerne abschalten können.

Schön, dass jemand was damit anfangen kann

Narses hat folgendes geschrieben :

Wenn ich noch eine kleine Anmerkung machen bzw. Wunsch äußern dürfte: kannst du den "Free Space"-Block in der TreeMap immer in Grau anzeigen (das macht WinDirStat auch), so dass man gleich sieht, dass das keine "Datei" ist?

Ist lokal implementiert.

SMO hat folgendes geschrieben :

Kleiner Feature-Request: die Anzeige des freien Speichers als eigenen Block würde ich gerne abschalten können.

Für die Treemap? Ja, sehr sinnvoll. Hab ich auf einer halbleeren Platte im Büro auch festgestellt Kommt auf die Liste.

SMO hat folgendes geschrieben :

Aber andererseits fühlt es sich ziemlich zäh an, wenn ich z.B. in der Listview per Tastatur navigiere (Pfeiltaste gedrückt halten, die rote Markierung des aktuellen Items in der Treemap wird aktualisiert, die Listview dagegen wird erst wieder neu gezeichnet wenn ich die Taste loslasse).

Stimmt, da sieht man das extrem, dass ich die ganze Treemap neu zeichne, nur um den Markierungsraumen da drauf zu bekommen. Blöde Idee eigentlich

SMO hat folgendes geschrieben :

Das negative "Unknown"-Problem von FinnO kann ich bestätigen. Passiert bei mir nur, wenn ich MDirStat als Admin starte. Mit normalen rechten bekomme ich immer noch einen Unknown-Block, dann aber mit 2,4 GB statt negativ.

Mit einer Testversion hat mir FinnO da grade etwas geholfen... MDirStat findet in diesem Fall mehr belegten Speicher, als laut Windows tatsächlich belegt ist. 129G auf einer 128G SSD, da passt also etwas nicht. Mir ist nur nicht klar wo das herkommt: andersrum hätte ich das jetzt eher erwartet, da die Verwaltungsinformationen ja nicht mitgerechnet werden.
Eine Idee: wie voll ist die betreffende Platte bei dir, SMO?

Martok hat folgendes geschrieben :

Mit einer Testversion hat mir FinnO da grade etwas geholfen... MDirStat findet in diesem Fall mehr belegten Speicher, als laut Windows tatsächlich belegt ist. 129G auf einer 128G SSD, da passt also etwas nicht. Mir ist nur nicht klar wo das herkommt: andersrum hätte ich das jetzt eher erwartet, da die Verwaltungsinformationen ja nicht mitgerechnet werden. Eine Idee: wie voll ist die betreffende Platte bei dir, SMO?

Ist bei mir ebenfalls auf einer 128 GB SSD aufgetreten, die ich als Systemlaufwerk benutze.
Ich nehme an, Hardlinks, NTFS Streams usw. berücksichtigst du alles. Wie sieht es mit Ordnern/Dateien aus, auf die man selbst mit Adminrechten keinen Zugriff erhält? Davon gibt es ja auf dem Systemlaufwerk ein paar. Oder könnte es Verschnitt sein?
Auf meiner 3 TB Datenplatte bekomme ich um die 755 MiB "Unknown" angezeigt. Der Wert hat sich seit gestern leicht geändert, aber was der Grund war weiß ich nicht.

SMO hat folgendes geschrieben :

Ich nehme an, Hardlinks, NTFS Streams usw. berücksichtigst du alles.

Hardlinks ja (indem sie nicht verfolgt werden), ebenso Mountpunkte (vgl. --one-file-system von diversen Unix-utils). ADS und größere Sicherheitsbeschreibungen (noch) nicht, die sollten dann aber grade nicht gezählt werden und später indirekt als Unknown auftauchen. Dafür ist der Eintrag eigentlich gedacht.

SMO hat folgendes geschrieben :

Wie sieht es mit Ordnern/Dateien aus, auf die man selbst mit Adminrechten keinen Zugriff erhält? Davon gibt es ja auf dem Systemlaufwerk ein paar. Oder könnte es Verschnitt sein?

Ebenso das. Beispiel: Papierkörbe anderer Benutzer.

Der Punkt ist: das alles erzeugt eine Situation, in der weniger Datenmenge gescannt wurde, als nach GetDiskFreeSpaceEx() belegt sein müssten. Die Differenz ist dann postiv und wird als "Unkown" gelistet. Bei euch ist die Differenz aber negativ - wir wissen von belegtem Speicher, der gar nicht belegt sein sollte. Das einzige was mir da einfällt, ist dass NTFS auf den letzten paar Prozent freiem Speicher nicht mehr den korrekten Wert als frei angibt, sondern etwas zu viel. Deswegen die Frage nach der Belegung.

Hier unmittelbar nacheinander aufgenommene Screenshots, einmal Adminrechten gestartet, einmal ohne.

Hallo,
das Problem mit dem Unknown-Bereich habe ich auch auf einer normalen Festplatte.
Als Administrator ausgeführt wird ein negativer Bereich angezeigt, als Nicht-Administrator 12,2 GiB bei 662 Gesamtgröße.

Beste Grüße
Mathematiker

Dank Mathematiker und FinnO, die mich mit Testdaten versorgt haben, gibt es zumindest Informationen:

Das Unknown-Problem ist größer als ich dachte (und, Bonus: das machen alle falsch. WinDirStat, altWinDirStat, Windows-Explorer, TotalCommander...). An sich ist die Ursache recht einfach, aber der Fix wird haarig, wenn das auch noch performant sein soll.

Hintergrund ist, dass es in Windows 3 Arten von Links gibt: Hardlinks, Junctions/Softlinks und Symlinks. Nur Junctions und Symlinks (und, IIRC, Mountpunkte) erhalten dabei das Attribut "FILE_ATTRIBUTE_REPARSE_POINT" (weil sie auch aus dem Dateisystem raus führen können). Hardlinks hingegen sind Dateisystemintern, es gibt also einfach mehrere Verzeichniseinträge die auf einen Datenstrom zeigen. Hardlinks sind deswegen kaum zu erkennen, aber belegen eben nur einmal Platz. Via FINDFIRSTFILENAMEW/ FINDNEXTFILENAMEW bekommt man alle Namen, unter der eine Datei erreichbar ist, sowie über GETFILEINFORMATIONBYHANDLE die Anzahl weiterer Einträge und eine eindeutige ID der Daten. Bedeutet aber ein zusätzliches Open/Stat/Close pro Datei, was ggf. langsam wird, da man es bei jeder Datein machen muss...

Problematisch ist das, weil Windows Update das massiv benutzt, praktisch der komplette WinSxS-Ordner ist von Hardlinks durchzogen. Auch auf meinen Systemen, so liegen hier z.B. knapp 50k Verzeichniseinträge mehr, als Datenströme existieren.

Das ist doch mal eine spannende Aufgabe

Martok hat folgendes geschrieben :

Das Unknown-Problem ist größer als ich dachte (und, Bonus: das machen alle falsch. WinDirStat, altWinDirStat, Windows-Explorer, TotalCommander...).

Das Problem mit den Links und dadurch mehrfach berechnetem Speicherplatz kenne ich... TreeSize macht das aber z.B. korrekt, das habe ich deshalb auch schon vor einer ganzen Weile gekauft. (Es gibt aber auch eine kostenlose Version.)
Alle stimmt also nicht ganz.

Das ist mal was anders! Avira meldet TR/ATRAPS.Gen2 wenn ich versuche das zip zu entpacken. False positive vermute ich mal, typisch für Avira.

Es gibt eine neue Version: 1.1, Download im ersten Beitrag.

Sichtbare Änderungen:

* Freespace und Unknown werden immer grau dargestellt * CSV-Baumdatenexport mit Tiefenangabe * Neuzeichnen bei Selektionsänderung repariert * Option: Freespace, Unknown in der Treemap ausblendbar * Erkennung von NTFS-Hardlinks * Anzeige weiterer Orte einer Datei/Link mit klickbarer Liste

Die Hardlinkerkennung muss vor dem Scan explizit in den Optionen aktiviert werden, da sie verdammt langsam sein kann. Es können außerdem immer nur Hardlinks innerhalb des gescannten Verzeichnis gefunden werden. Nach dem Scan kann man sich dann im "Hardlink Inspector" andere Links zu einer Datei anzeigen lassen.

jaenicke hat folgendes geschrieben :

Das Problem mit den Links und dadurch mehrfach berechnetem Speicherplatz kenne ich... TreeSize macht das aber z.B. korrekt, das habe ich deshalb auch schon vor einer ganzen Weile gekauft. (Es gibt aber auch eine kostenlose Version.) Alle stimmt also nicht ganz.

Lustigerweise ist das der Laden, der seit einiger Zeit für VirtualTreeview verantwortlich ist

Sinspin hat folgendes geschrieben :

Das ist mal was anders! Avira meldet TR/ATRAPS.Gen2 wenn ich versuche das zip zu entpacken. False positive vermute ich mal, typisch für Avira.

Nicht nur Delphi, jetzt auch Freepascal. Ist das jetzt ein Reife-Zeugnis? Ich hab mir mal den Spaß gemacht und die 1.1 gescannt.

Nach einer "kleinen" Weile heute eine neue Version, Download im ersten Beitrag.

Es gibt nur einen einzigen Bugfix: der Verzeichnisauswahldialog wurde nicht immer sauber initialisiert.

Ansonsten nur Updates von Compiler und LCL sowie eine kleine Code-Reorganisation vom Infodialog. Auf besonderen Wunsch ist es jetzt auch möglich, eine Version zu compilieren die unter Windows 2000 funktionsfähig ist (also weniger Abhängigkeiten auf moderne Funktionen hat). Sollte da jemand Binaries brauchen, könnt ihr euch gern melden.

- Nachträglich durch die Entwickler-Ecke gelöscht -

Für Dateien ist das SHGetFileInfo, genau. Allerdings rufe ich die für jede Erweiterung nur einmal auf, die landen dann in einem Cache.
Ordner, Junctions und die Unknown und Free Blöcke sind aber einfach nur statisch zugeordnete Bilder aus einer ImageList (naja, aus einer Hybridliste - die ersten paar Elemente sind statische Bilder, dann werden die aus dem System angehängt. Ist aber nur so weil man dem TreeView ja nur eine Liste zuweisen kann).

In der Ordnerauswahl beim Start kommen die Grafiken auch aus der SystemImageList, irgendwelche Magie ist da nicht dabei .

- Nachträglich durch die Entwickler-Ecke gelöscht -

Ich habe das Tool erst heute wieder benutzt und mich sehr gefreut

Allerdings hätte ich noch einen Feature Request: Und zwar würde ich gerne Dateien filtern können. Konkret wollte ich wissen, welches von 14 Projekten denn am meisten Code enthält. Dazu wollte ich erst MDirStat benutzen, aber es gab noch zahlreiche andere (nicht *.cs) Dateien in den Ordnern.
letzlich habe ich einfach alles andere gelöscht und bin zum Ziel gekommen - aber das geht ja nicht immer.

Insofern fände ich es sehr cool, wenn man einen Dateinamensfilter angeben könnte wie "*.zip" oder "XY*.pas" und dann werden nur solche Dateien berücksichtigt.

Wäre das jetzt auf github würde ich mir auch einen PR zutrauen