Größe von tatsächlichem Verzeichnisinhalt messen in Byte

[DeletedUserReAsG]

OT ist’s ja eh schon. Aber wenn du zur Überprüfung deiner Transfers alleine schaust, ob die Zahl der übertragenen Bytes richtig ist, kannst du’s eigentlich auch ganz lassen. Dass Bytes fehlen, wäre ein eher seltener Fall, der außerdem mit einiger Wahrscheinlichkeit eh einen Übertragungsfehler wirft. Viel häufiger (aber immer noch sehr selten bei intakter Hardware, insbesondere RAM) kippt beim Schreiben (nach der eigentlichen Übertragung – die ist in aller Regel selbst dahingehend abgesichert) tatsächlich ein Bit, und dem begegnet man am besten mit einer Prüfsumme (CRC32 reicht da schon – da sind zwar auch noch Fehler möglich, aber doch sehr unwahrscheinlich – dafür ist es schnell), statt mit Erbsen … ähm … Bytes zählen.

Wenn’s für dich okay ist, und dir deswegen die theoretische Größe der Datei anhand ihres Inhalts ausreicht, ist da nix gegen zu sagen. Ich möchte jedoch Mitlesern stark davon abraten, auf so eine Weise die Integrität ihrer Filetransfers zu prüfen. Das ist nur Schlangenöl.

[dolphin]

Nochmal Thema Brutto versus Netto:

Gerade eben hatte ich einen schönen Anwendungsfall, bei dem mir ein Brutto überhaupt nichts gebracht hätte, ein Netto mir aber geholfen hatte:

Ich hatte Daten von ext3 auf einen USB-Stick (fat16 oder so) kopiert. Es waren mehrere Verzeichnisbäume.

In einem Verzeichnis war ein Symlink drin. Symlinks können aber nicht in Fat16 gespeichert werden, also meldete der Midnight Commander einen Fehler. Ich sagte dann 'skip'.

Danach wollte ich wissen, ob außer dem Symlink alles Andere drauf war. Ich maß die Verzeichnisse von Quelle und Ziel durch. Alle Verzeichnisse hatten die gleiche Größe, bis auf eins. Da fehlte nur der Symlink, also war alles OK.

Mit einer Brutto-Messmethode hätte ich die Frage, ob alles OK ist, niemals nie so einfach beantworten können.

Netto war hier die einzig sinnvolle Messmethode. Und in solchen Fällen bin ich froh, dass ich Tools habe, die so messen können, wie ich es für richtig halten: Netto.

Wollte ich auf die Schnelle nur mal loswerden...


dolphin

[geier22]

Naja - habt euch ja richtig Mühe gegeben.
warum nicht einfach:

Code: Alles auswählen

 apt install k4dirstat

ergibt dann:

[DeletedUserReAsG]

… und man kann damit auch bytegenau den richtigen Wert anzeigen (worum’s ja in diesem alten Thread ging)? Das geht aus deinem Screenshot nicht hervor – da ist’s z.T. gerade mal auf 100MB genau, und welcher Wert das ist, steht da auch nicht.

[geier22]

Hallo!
Die Aufgabenstellung lautet:

Ermittle mit einem Standardwerkzeug die tatsächliche Größe aller Dateien
in einer geschachtelten Verzeichnishierarchie, ohne erst ewig lang programmieren
zu müssen..

Danach wurde nicht gefragt. Allerdings ist k4dirstat das einzig mir bekannt Programm das auch die Menge der Dateien in einem Verzeichnis
und nicht nur die Objekte ( das sind dann in der Regel, wenn Unterverzeichnisse bestehen nur die Unterverzeichnisse) anzeigt. Wenn ich die Verzeichnisse öffne, hab ich auch kilobyte und byte, je nach Größe der Dateien

… und man kann damit auch bytegenau den richtigen Wert anzeigen (worum’s ja in diesem alten Thread ging)?

Diese Aufgabe hat sich dann in laufe des Threads "entwickelt.

[DeletedUserReAsG]

Ähm … nein, das steht alles im ersten Beitrag: dass es die tatsächliche Größe sein soll, und das Bytes als Einheit gefragt sind (das steht gar schon im Threadtitel).

[geier22]

Das kannst du aber mit mc machen. Allerdings hast du dann keinen Überblick, da MC Überverzeichnisse generell mit 4096 byte anzeigt, unabhängig, was sich dahinter versteckt (wage zu bezweifeln ob das stimmt k4dirstat zeigt da andere Werte an).
Der Totalcommander zeigt übrigens bei Verzeichnissen, die Unterverzeichnisse haben auch nur <Dir> an, genauso wie alle Dateimanager unter Linux auch.

[DeletedUserReAsG]

Ist ja schön, aber darum ging’s hier halt nicht. Mehr wollte ich gar nicht ausgedrückt haben.

[dolphin]

Hi!

Ich hab mal k4dirstat getestet. Es hat drei Probleme, die ich nicht lösen konnte:

• Es zeigt Verzeichnisgrößen in Brutto statt in Netto an. Ich brauch es netto.
• Es zeigt Verzeichnisgrößen in kB, MB und GB an, ich brauch es aber in Byte. Die Angaben in kB, MB und GB müssten idealerweise optional sein. Wenn sie aber die einzig verfügbare Maßeinheit sind, dann empfinde ich das als unfreundlich.
• Es zickt bei Symlinks herum: Wenn ich die Größe eines Verzeichnisses messen will, dann muss ich als Argument das Oberverzeichnis übergeben, um dann die Größen der darin befindlichen Unterverzeichnisse zu sehen. Wenn ich nun aber als Oberverzeichnis einen Symlink übergebe, dann kommt nichts Gescheites dabei heraus. Das empfinde ich ebenfalls als unfreundlich mir gegenüber.

k4dirstat ist aus diesen Gründen daher nichts für mich.

Was den Midnight-Commander betrifft, da möchte ich die Aussage von geier22 korrigieren:

da MC Überverzeichnisse generell mit 4096 byte anzeigt

Das stimmt nur teilweise:

• In der Standardansicht zeigt der 'mc' Verzeichnisse als 4096 Byte groß an. Aber die Standardansicht hilft mir bei Verzeichnissen nicht weiter, und daher ignoriere ich sie bei Verzeichnissen.
• Wenn ich Verzeichnissgrößen messen will, dann geh ich mit dem Cursor-Balken auf '..' und drücke <Ctrl>+<Space> für 'Command' - 'Show directory sizes'. Nun wird die tatsächliche Verzeichnisgröße in Netto angezeigt. Bei leeren Verzeichnissen wird dann korrekt die Größe angezeigt, die dem entspricht, was da drin ist: 0 Byte.

Viele Grüße,
dolphin

[dolphin]

Dieser Thread ist jetzt schon über 4 Jahre alt, aber immer dann, wenn ich froh bin, dass meine Systeme die Dateigrößen netto statt brutto messen (so wie es sein muss), bin ich froh darüber, dass sie eben netto und nicht brutto gemessen werden.

Gerade habe ich einen schönen Use-Case gefunden, der aufzeigt, warum Netto immer besser als Brutto ist.

Aktuellstes Beispiel:

• Ich habe auf Windows 7 eine YAML-Datei (AWS-CloudFormation) herumliegen, die ich schon nach S3 hochgeladen habe. Die ist fehlerhaft, ich korrigiere sie und will sie erneut nach S3 hochladen.

• Die alte Version ist netto 3914 Byte groß.

• Die neue Version ist 3933 Byte groß.

• Brutto sind sie unter Windows 7 beide jeweils 4096 Byte groß.

• Wenn ich jetzt sichergehen will, dass nach dem Hochladen wirklich die neuste Version im S3-Bucket liegt, dann guck ich auf der AWS-Oberfläche im Web-Browser einfach auf die Dateigröße.

• Wenn da jetzt eine 3914 angezeigt wird, dann hab ich die falsche Version (die alte) hochgeladen.

• Wenn aber eine 3933 angezeigt wird, dann liegt die richtige YAML-Datei im Eimer und ich kann anfangen, die Infrastruktur zu generieren.

Diskussion:

• Weil ich ein bequemer Mensch bin, missbrauche ich hier die Dateigröße als Quersumme (sozusagen als Hash).

• Die nützt mir hier aber nur etwas, wenn alle beteiligten Systeme die Dateigröße netto anzeigen.

• Würden die Systeme sie brutto anzeigen, dann würde Windows 7 zwei mal jeweils 4096 Byte nennen (was es auch tut, denn Windows zeigt ja beide Varianten an, nämlich netto und brutto), Amazon würde mir auch irgendeine komische Zahl doppelt anzeigen und mein Use-Case (das Missbrauchen der Dateigröße als Hash) wäre unnötigerweise komplett tot.

Nun ja, das sind die kleinen Dinge im Leben, wo ich immer froh bin, dass ich netto statt brutto angezeigt bekomme (oder Beides und ich such mir jeweils netto raus).

Und immer wieder denke ich an diesen alten Thread. Es wurde Zeit, dass ich ihn mal wieder ausgrabe, denn so oft, wie ich an diese Diskussion denke, hat der Thread es verdient, wieder ausgegraben zu werden

[ernohl]

Und immer wieder denke ich an diesen alten Thread. Es wurde Zeit, dass ich ihn mal wieder ausgrabe, denn so oft, wie ich an diese Diskussion denke, hat der Thread es verdient, wieder ausgegraben zu werden

Ich habe den Thread jetzt überflogen, wenn er das "Ausgraben" schon verdient hat. Wenn ich dich richtig verstanden habe, geht es dir um die Kontrolle der Vollständigkeit und Übereinstimmung aller Dateien in zwei Verzeichnissen (inkl. Unterverzeichnissen). Richtig?

Für diesen Fall würde ich mich lieber auf die Prüfsumme verlassen und rsync zu Hilfe nehmen, z.B. so

Code: Alles auswählen

rsync -avH --dry-run --checksum --delete ...

Hast du diese Variante bedacht?

[dolphin]

Ich arbeite grundsätzlich mit verschiedenen Plattform-Typen, da ist mit rsync in der Regel nicht viel zu machen, denn rsync würde ja voraussetzen, dass es sowohl auf dem Quellsystem als auch auf dem Zielsystem läuft.

[schwedenmann]

Hallo

Ich arbeite grundsätzlich mit verschiedenen Plattform-Typen, da ist mit rsync in der Regel nicht viel zu machen, denn rsync würde ja voraussetzen, dass es sowohl auf dem Quellsystem als auch auf dem Zielsystem läuft.

rsync geht unter MAc und unter win nimmst du cgwin + rsync + ssh


mfg
schwedenmann

[wanne]

Nochmal eine kleine Anmerkung zu dem:

Da fehlte nur der Symlink, also war alles OK.

Du willst ernsthaft ein Tool haben, das Ordner als 0Byte zählt aber Links als >0byte. Und warte wie groß sollen die denn sein?
Ist doch Dateisystemabhängig!
Wäre es ein Hardlink gewesen wäre es auf jeden Fall nicht aufgefallen. Die sind nämlich NNetto auf jeden Fall 0 Byte.

Ich hatte Daten von ext3 auf einen USB-Stick (fat16 oder so) kopiert.

Dann sollte dir eigentlich sowohl netto wie Brutto andere Größen herauskommen:
Hintergrund: fat16 Kann lediglich 8.3 => Keine Kleinbuchstaben, keine Sonderzeichen Nicht mehr als 8 Zeichen im Namen...
Die meisten modernen Betriebssysteme Legen deswegen als Hint den richtigen Dateinamen in eine versteckte Datei neben der Originalen mit verfälschtem Namen. Ein Tool, das stumpf die Größe aller Dateien vergleicht (also auch Symlinks mitzählt) sollte entsprechend auch diese Dateien mit zählen. – Und entsprechend deutlich mehr Daten finden.

Andere Sache ist, wenn du wirklich ein DOS-Kompatibles System nimmst (mount -t dosfs oder so.) Dann sind alle deine Dateinamen weg aber der Fehler fällt bei deiner Zählweise nicht auf.
Noch lustiger wird das btw. mit Bildern unter Windows. Da hängt Windows ganz gerne was als Metadatum dran. Die sind dann nach deiner "Netto"-Zählweise keine Daten. Diese sind dann logischerweise 0Byte. Kann dir unter Windows ausdruckbare Bilder machen, die netto 0byte haben aber sich ausdrucken lassen. Kopiert man das dann auf ein FAT funktioniert das nicht. Man kopiert nur die leeren Daten. Die Größe insgesamt ändert sich aber nicht. x-0=x Selbiges gilt auch für wirklich leere Dateien. (Gibt genug Sachen, wo nur der Dateiname relevant ist.)
Da gibt es eine ganze Menge Fallstricke. Es ist einfach eine verdammt dumme Idee. "netto"-Daten zu vergleichen. Nimm rsync! Das läuft überall.

[kalamazoo]

Bin auf diesen Uralt-Thread gestossen und fand ihn durchaus lesenswert. Mich interessiert die Off-Topic-Bemerkung:

Die meisten modernen Betriebssysteme Legen deswegen als Hint den richtigen Dateinamen in eine versteckte Datei neben der Originalen mit verfälschtem Namen.

Dazu meine Ad-Hoc-Frage: Wie finde ich eine derartig versteckte Datei (ist das wirklich eine eigene Datei mit Inode etc. oder sind es bloß Metadaten?) und wie kann ich sie auslesen?

[wanne]

Dazu meine Ad-Hoc-Frage: Wie finde ich eine derartig versteckte Datei (ist das wirklich eine eigene Datei mit Inode etc. oder sind es bloß Metadaten?) und wie kann ich sie auslesen?

Mag ein bisschen spät kommen. Aber: FAT hat ne FAT und eben keine inodes. Da ist halt je nach Definition nichts mit Metadaten oder die Dateien, die Metadaten enthalten. Ein aktuelles Tool, dass das visualisiert kenne ich nicht. Aber ich glaube ältere Versionen von Testdisk habend das als gelöschte Datei angezeigt.

[kalamazoo]

Mag ein bisschen spät kommen.

Danke @wanne, ist angekommen! Um diesen Thread nicht ganz zu kapern, werde ich hinsichtlich meiner Fragen zu den verschiedenen Dateisystemen einen eigenen eröffnen.