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

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 26.07.2014 19:42:27

Hallo!

Ein Windows-Anwender konfrontierte mich (Linux-Anwender) heute mit
einer Frage, bei der ich passen musste.
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..
Unter Windows mit dem richtigen Werkzeug (sagen wir mal Total Commander) ist
das kein Problem. Zuerst dachte ich, er will mich auf den Arm nehmen, aber nach
mehreren Minuten Recherche, Man-Page-Lesen und Ausprobieren, stellten wir fest,
dass diese einfache Aufgabe mit Linux eine riesige Herausforderung ist.

Versuchsaufbau

Ich bastle mir ein paar Dateien, lege ein paar Verzeichnisse an und
kopiere / schiebe die Dateien da hin:

Code: Alles auswählen

#!/bin/bash

>24_byte.txt
echo -e -n "abcdefghijklmnopqrstuvw\n">>24_byte.txt

>100_byte.txt
for loop in `seq 1 9`; do echo -e -n "1234567890">>100_byte.txt; done
echo -e -n "123456789\n">>100_byte.txt

>1000_byte.txt
for loop in `seq 1 10`; do cat 100_byte.txt>>1000_byte.txt; done

>1024_byte.txt
for loop in `seq 1 10`; do cat 100_byte.txt>>1024_byte.txt; done
cat 24_byte.txt>>1024_byte.txt

>7000_byte.txt
for loop in `seq 1 7`; do cat 1000_byte.txt>>7000_byte.txt; done

>1_MiB.txt
for loop in `seq 1 1024`; do cat 1024_byte.txt>>1_MiB.txt; done

>1_GiB.txt
for loop in `seq 1 1024`; do cat 1_MiB.txt>>1_GiB.txt; done

>2_GiB.txt
for loop in `seq 1 2`; do cat 1_GiB.txt>>2_GiB.txt; done

mkdir 28000_byte
mkdir 28000_byte/7000_byte
mkdir 28000_byte/14000_byte
mkdir 28000_byte/14000_byte/7000_byte
mkdir 3_GiB

cp -a 7000_byte.txt 28000_byte
cp -a 7000_byte.txt 28000_byte/7000_byte
cp -a 7000_byte.txt 28000_byte/14000_byte
cp -a 7000_byte.txt 28000_byte/14000_byte/7000_byte
mv 1_GiB.txt 3_GiB
mv 2_GiB.txt 3_GiB

Das Resultat sind diese sich selbst erklärenden zwei Verzeichnishierarchien
namens '28000_byte' und '3_GiB':

Code: Alles auswählen

28000_byte
|
+- 14000_byte
|  |
|  +- 7000_byte
|  |  |
|  |  +- 7000_byte.txt
|  |
|  +- 7000_byte.txt
|
+- 7000_byte
|  |
|  +- 7000_byte.txt
|
+- 7000_byte.txt

3_GiB
|
+- 1_GiB.txt
|
+- 2_GiB.txt

Und nun die Experimente

Die Herausforderung besteht darin, einen allgemeingültigen Weg zu finden,
wie man die Größen der zwei Verzeichnisse '28000_byte' und '3_GiB' messen kann.

Versuch 1: Midnight Commander

Ich drücke <Ctrl>+<Leertaste>, um das Kommando 'show directory sIzes' aufzurufen.

Dann kann ich jeweils mit der <Einfügen>-Taste ein Verzeichnis markieren,
und unten sehe ich dann jeweils:
  • 28,000 bytes in 1 file
  • 3,145,728K bytes in 1 file
Das sind zwei Ergebnisse. Eins ist korrekt, das andere aber ist falsch. Das
erste Ergebnis zeigt mir korrekt 28000 Byte an. Das andere Ergebnis lautet
3145728 Kibibyte. Das entspricht aber nicht der Aufgabenstellung, denn erstens
ist die Angabe in Kibibyte zu ungenau, weil die letzten 3 Ziffern fehlen und
zweitens wollten wir eben Byte haben und eben nicht Kibibyte, und auch nicht
Kilobyte.

Versuch 2: du

Es war naheliegend, es mit 'du' zu versuchen, doch, was 'du' als Ergebnis
abliefert, das ist einfach nur der Hammer. Egal, welche Argumente man ihm
verfüttert, die Ergebnisse sind falsch, falsch und wieder falsch.

Das Tool 'du' misst unter anderem die Größe, die ein Verzeichnis verbraucht,
und es misst, wie viel Platz die Dateien auf der Platte brauchen, aber nicht,
wie groß sie tatsächlich sind. Dann gibt es da noch dieses
komische '--apparent-size', aber auch das liefert nicht das gewünschte Ergebnis.

Versuch 3: ncdu

Ein Google-Treffer lieferte den Hinweis, es mal mit ncdu zu versuchen.
Hab ich gemacht. Hier sind die Ergebnisse:

Code: Alles auswählen

+---Item info----------------------------------------------+
|                                                          |
|  Name: 3_GiB                                             |
|  Path: /multi/sandbox                                    |
|  Type: Directory                                         |
|                                                          |
|     Disk usage:   3.0GiB (3.224.383.488 B)               |
|  Apparent size:   3.0GiB (3.221.229.568 B)               |
|                                                          |
|                               Press i to hide this window|
+----------------------------------------------------------+
[code]

+---Item info----------------------------------------------+
| |
| Name: 28000_byte |
| Path: /multi/sandbox |
| Type: Directory |
| |
| Disk usage: 48.0kiB (49.152 B) |
| Apparent size: 43.3kiB (44.384 B) |
| |
| Press i to hide this window|
+----------------------------------------------------------+
[/code]

Wir sehen hier zwar, dass sich 'ncdu' um eine Angabe in Byte bemüht,
auch bei dem Verzeichnis mit dem Namen '/multi/sandbox/3_GiB', aber
insgesamt sind die Ergebnisse, die 'ncdu' meldet, leider wieder
falsch:

  • Weder 3.224.383.488 B, noch 3.221.229.568 B, sondern 3.221.225.472 B wären korrekt gewesen.
  • Weder 49.152 B, noch 44.384 B, sondern 28.000 B wären korrekt gewesen.
Lösung?

Die Frage lautet also:

Wie bekomme ich unter Linux mit einem Standardwerkzeug heraus,
ohne lange programmieren zu müssen, dass das Verzeichnis '3_GiB'
3221225472 Byte und das Verzeichnis '28000_byte' 28000 Byte groß ist?

Besten Dank im Voraus,
dolphin

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von catdog2 » 26.07.2014 20:11:19

Wie bekomme ich unter Linux mit einem Standardwerkzeug heraus,
ohne lange programmieren zu müssen, dass das Verzeichnis '3_GiB'
3221225472 Byte und das Verzeichnis '28000_byte' 28000 Byte groß ist?

Code: Alles auswählen

 % find 28000_byte -type f -print0 | du --files0-from=- -c -b
7000    28000_byte/14000_byte/7000_byte.txt
7000    28000_byte/14000_byte/7000_byte/7000_byte.txt
7000    28000_byte/7000_byte.txt
7000    28000_byte/7000_byte/7000_byte.txt
28000   total

Code: Alles auswählen

% find 3_GiB -type f -print0 | du --files0-from=- -c -b     
2147483648      3_GiB/2_GiB.txt
1073741824      3_GiB/1_GiB.txt
3221225472      total
Egal, welche Argumente man ihm
verfüttert, die Ergebnisse sind falsch, falsch und wieder falsch.
Nein du interpretierst sie nur falsch.
Dein Problem ist, dass du auch die Größen der Verzeichnisse selbst mit einrechnet.
Zuletzt geändert von catdog2 am 26.07.2014 20:26:49, insgesamt 1-mal geändert.
Unix is user-friendly; it's just picky about who its friends are.

cosmac
Beiträge: 4573
Registriert: 28.03.2005 22:24:30

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

Beitrag von cosmac » 26.07.2014 20:21:53

hi,

"find -f" findet doch nur normale Files, also keine Dirs?
Und "stat" statt "du" liefert auch die echte Byte-Anzahl.

Code: Alles auswählen

echo $((0$(stat -c'+%s' $(find . -type f -print))))
Zuletzt geändert von cosmac am 26.07.2014 20:28:42, insgesamt 1-mal geändert.
Beware of programmers who carry screwdrivers.

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von catdog2 » 26.07.2014 20:26:23

"find -f" findet doch nur normale Files, also keine Dirs?
dolphin scheint doch genau das zu wollen.
Und "stat" statt "du" liefert auch die echten Byte-Anzahl.
Ob man da jetzt stat oder du nimmt ist letztendlich egal, du kann sie immerhin selbst zusammenzählen.

//edit: außerdem stribt mein ansatz nicht mit argument list too long bei vielen dateien. ;)
Zuletzt geändert von catdog2 am 26.07.2014 20:29:07, insgesamt 1-mal geändert.
Unix is user-friendly; it's just picky about who its friends are.

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 26.07.2014 20:29:02

Hi!

Das ist ja schön, das schon mal eine funktionierende Lösung gepostet wurde.

(Und in der Tat, ich will nur die Dateigrößen messen. Die Größen der Verzeichnisse sind immer 0!)

Notfalls programmieren wir uns also irgendwann mal ein Shell-Skript und legen es in ein 'bin'-Verzeichnis.

Aber, bevor wir soweit gehen: Hat jemand noch eine andere Lösung, die weniger kompliziert ist, also ohne dem 'find'-Befehl auskommt? Etwas, wo man gar nicht erst programmieren muss?

dolphin

cosmac
Beiträge: 4573
Registriert: 28.03.2005 22:24:30

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

Beitrag von cosmac » 26.07.2014 20:48:40

dolphin hat geschrieben:Etwas, wo man gar nicht erst programmieren muss?
Shell-Einzeiler sind doch keine Programme ;)
Außerdem: wenn Total Commander als Standardwerkzeug zählt, müsstest du eigentlich alle Linux-Dateimanager durchprobieren...
Beware of programmers who carry screwdrivers.

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 26.07.2014 20:52:25

Die Größen der Verzeichnisse sind immer 0!
Sind sie nicht.

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 27.07.2014 09:53:34

So, über Nacht kam mir eine entscheidende Idee, und die führte zur Lösung.

Also: Ich erinnerte mich, dass mir vor wenigen Monaten ein ZTreeWin-Anwender einen Crash-Kurs für die Arbeit mit ZTreeWin gab.
Nun läuft auf dem vServer, den der ursprüngliche Windows-Anwender betreibt, allerdings kein Windows (also auch kein ZTreeWin), sondern ein Debian-Linux (glaub ich zumindest, er ist ja noch nicht wach, also kann ich ihn noch nicht fragen), aber es gibt ja ytree.

So, und nun gebe ich allen, die es interessiert, einen kleinen Crash-Kurs in die Arbeit mit ytree, um mit ytree das oben beschriebene Problem elegant zu lösen.

Los geht's.

Installation

Code: Alles auswählen

apt-get install ytree
Starten

Code: Alles auswählen

ytree
'ytree' übernimmt beim starten das aktuelle Verzeichnis.
Wer also seine Navigation mit ytree abkürzen will, kann ja zunächst mit dem Midnight Commander in ein Verzeichnis navigieren, dann dort eine xterm aufmachen (oder auf dem vServer per 'cd' in das Verzeichnis von Interesse navigieren), und dann ytree starten, um dort gleich im richtigen Verzeichnis zu landen.

Das mach ich jetzt also mal:

Code: Alles auswählen

cd /multi/sandbox
ytree
Basics
Fangen wir mit dem Wichtigsten an: Wie kann man ytree nach getaner Arbeit wieder beenden?
- <Q>uit
- <Y>es

Nachdem wir wissen, wie wir rein und wieder raus kommen, bleiben wir jetzt drin und stellen fest, dass es 3 wesentliche Sichten gibt, zwischen denen wir per <Return>-Taste hin- und herschalten können. Initial befindet sich 'ytree' laut man-Page im DIR-Modus. Reihum können wir nun toggeln:
- Enter = FILE-Modus
- Enter = expand modus
- Enter = DIR-Modus

Laut Man-Page gibt es zusätzlich noch den ARCHIV-DIR-Modus und den ARCHIV-FILE-Modus, aber diese Modi brauchen wir ja nur, wenn wir ZIP-Archive oder tar.gz-Archive oder sowas untersuchen wollen. Wollen wir aber nicht, uns interessieren nur die Verzeichnisse auf dem Rechner, also interessieren und diese ARCHIV-Modi nicht weiter.

Jetzt wissen wir also schon mal, dass die <RETURN>-Taste die wichtigste Taste in diesem Programm ist.

Ganz wesentlich sind auch die Konzepte Logging und Tagging. In der ZTreeWin-Welt offenbar wohl noch viel mehr als in der abgespeckten ytree-Welt.

Tagging
Im DIR-Modus kann ich per '<T>ag' und per '<U>ntag' einzelne Verzeichnisse taggen oder untaggen. Auf die getaggten Verzeichnisse kann man dann grundsätzlich (soweit ich das verstanden habe) verschiedene Operationen anwenden, wie etwa Löschen, Kopieren, Sichten und so weiter.

Die Welt des Taggens ist total wichtig, wenn man die Fähigkeiten der Tools ZTreeWin oder 'ytree' bis ins kleinste Detail ausreizen will. Wollen wir jetzt aber nicht, wir konzentrieren uns stattdessen auf das zu lösende Problem.

Logging
Das andere wichtige Konzept ist das Logging. Das hilft uns weiter. Normalerweise (mit ZTreeWin) holt man sich (soweit ich mich an den Crash-Kurs erinnere) mit dem Logging verschiedene Laufwerksbuchstaben in die engere Wahl. Da wir mit ytree arbeiten (und es unter Linux keine Laufwerksbuchstaben gibt), ist das hier mit dem Logging alles ein wenig primitiver.

Ich möchte jetzt das Verzeichns '28000_byte' näher untersuchen. Das logge ich jetzt. Und zwar so:

- im DIR-Modus das Verzeichnis selektieren
- <L>og
- 'ytree' schlägt jetzt den Pfad "/multi/sandbox/28000_byte" vor
- ich akzeptiere mit <RETURN>

Jetzt habe ich '28000_byte' geloggt. Das heißt:
Der DIR-Modus befasst sich nun ausschließlich mit diesem Verzeichnis. Alles andere blendet er aus.

Auf- und Zuklappen
Im DIR-Modus kann ich mich mit <Pfeil hoch> und <Pfeil runter> vertikal bewegen. Das heißt: Die Selektion wandert hoch und runter.
Wenn ich ein Verzeichnis meiner Wahl mit <Pfeil hoch> / <Pfeil runter> selektiert habe, dann kann ich es per <Pfeil rechts> aufklappen und per <Pfeil links> zuklappen. Der Midnight Commander nennt dieses Feature "Lynx-like motion". So nenne ich das jetzt auch.

Per "Lynx-like motion" können wir nun also alle Unter- und Unterunter-Verzeichnisse aufklappen, die uns näher interessieren.

Bei einer tiefen, stark verästelten Verzeichnishierarchie macht das aber keinen Spaß, weil es einfach anstrengend ist, per "Lynx-like motion" 5 Minuten lang nur damit beschäftigt zu sein, um alles aufzuklappen, was wir betrachten wollen. Es gibt 3 weitere Tasten, die hier die Arbeit von 5 Minuten auf eine hundertstel Sekunde abkürzen:

- <+> den selektierten Baum um eine Ebene aufklappen (das Gleiche wie <Pfeil rechts>)
- <-> den selektierten Baum komplett zuklappen (das Gleiche wie <Pfeil links>)
- <*> den selektierten Baum komplett aufklappen (das ist im Endeffekt das, was uns die Zeit spart)

Die Größe der Verzeichnisinhalte ermitteln
So. Nochmal für alle, die es bis jetzt noch nicht verstanden haben: Die Größe eines Verzeichnisses ist immer 0.
Natürlich belegt ein Verzeichnis im Dateisystem auch Speicher. Aber das interessiert uns nicht. Wir wollen NICHT den Overhead messen, sondern NUR den Inhalt von Dateien.

Auf der rechten Seite im 'ytree'-Fenster gibt es die 'DISK Statistics'. Die zeigt an, wie viele Dateien sich in den im DIR-Modus angezeigten Verzeichnissen befinden, und wie groß diese Dateien insgesamt sind. Und zwar in Byte. Ich habe das getestet unter Debian Lenny und Debian Sqeeeze. Den Wheezy-Prototyp-Rechner schalte ich jetzt mal nicht ein. Bin ich zu faul dazu.

Testen wir das Ganze jetzt mal mit dem Verzeichnis '28000_byte'.
- '28000_byte' im DIR-Modus per <Pfeil hoch> / <Pfeil runter> selektieren
- <*> drücken, um es komplett aufzuklappen
Und nun steht rechts:

Code: Alles auswählen

DISK Statistics
Total
Files:           4
Bytes:      28.000
Jetzt das Gleiche mit '/multi/sandbox/3_GiB':
- loggen
- selektieren
- mit <*> aufklappen

Ergebnis:

Code: Alles auswählen

Files:           2
Bytes:  3221225472
Rechnen wir per 'bc -l' nach:

Code: Alles auswählen

3221225472/1024/1024/1024
3.00000000000000000000
Das Ergebnis lautet exakt 3 GiB, also hat 'ytree' tatsächlich ein korrekes Ergebnis in Byte ausgegeben.

Nochmal eine tiefe, stark verästelte Verzeichnishierarchie auf einer externen Backup-Festplatte messen. Ergebnis:

Code: Alles auswählen

Files:        3.316
Bytes: 440504147267
Na, geht doch! Super! Mit der Methode kann ich 440 Gigabyte aufs Byte genau messen!

Selbst in Terabyte-Regionen scheint 'ytree' korrekte Ergebnisse zu liefern, auch wenn es dann optisch nicht mehr ganz so gut aussieht. Aber die Korrektheit ist sicherlich wichtiger als die Optik.

Ein Test:
- Ich logge das '/'-Verzeichnis
Da ja unter Linux das '/proc'-Verzeichnis 128 Tebibyte groß ist, zeigt 'ytree' diese auch an, und zwar so:
- rechts steht die Zahl '14073761892552'
- links auf der nächsten Zeile steht noch eine '1'
Ketten wir das mal zusammen, dann kommen wir auf '140737618925521'.
Schnel mal per 'bc -l' nachgerechnet:

Code: Alles auswählen

140737618925521/1024/1024/1024/1024
128.00011875289874296868
Wir kommen auf 128 Tebibyte.

Naja, 'ytree' schreibt zwar über den Rand hinaus, aber dank Zeilenumbruch geht nichts verloren, und das Ergebnis ist auch bei 128 Tebibyte noch korrekt.

Fazit
Jetzt gibt es schon mal zwei grundsätzliche Lösungansätze:
A) Man schreibt sich ein Shell-Skript, das einen 'find'-Befehl enthält, und legt es in einem 'bin'-Verzeichnis ab.
B) Man freundet sich mit 'ytree' an.

Im Prinzip ist das jetzt Geschmackssache.

Ich hoffe, dass ich hiermit für die Nachwelt das Thema ein für allemal geklärt habe.

dolphin

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

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

Beitrag von catdog2 » 27.07.2014 09:57:24

Und das soll jetzt einfacher sein als ein kurzer Shell Einzeiler?
Unix is user-friendly; it's just picky about who its friends are.

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 27.07.2014 10:11:23

Für jemanden, der lieber mit einem Tool als mit Shell-Gefrickel arbeitet, vielleicht.

Das Tool kann man ja auf dem Zielrechner mal schnell installieren. Den Shell-Einzeiler müsste man sich erst wieder irgendwo aus einer Know-how-Sammlung besorgen.

Welche Variante einfacher ist, das soll besser die Person beantworten, die vor dem zu lösenden Problem steht.

Ich finde es wichtig, dass man die Wahl hat. Und mit 'ytree' hab ich hiermit eine Alternative für diejenigen ausgearbeitet, die lieber keine Shell-Einzeiler zusammenfrickeln wollen.

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 27.07.2014 10:22:40

Das Tool kann man ja auf dem Zielrechner mal schnell installieren. Den Shell-Einzeiler müsste man sich erst wieder irgendwo aus einer Know-how-Sammlung besorgen.
Und bei dem „Tool“ muss man dann noch schnell deine ewig lange Anleitung lesen, während man beim Einzeiler nur auf Enter zu drücken braucht. Aber wie du schon schriebst: kann jeder machen, wie er will. Ein nativer Windowsuser wird mit beiden Wegen nix anzufangen wissen, und ein nativer Linuxuser wird sich fragen „Und … wozu ist das gut?“. Mir z.B. erschließt sich die praktische Relevanz nicht – für mich ist in dem Kontext eher wichtig zu wissen, wieviel Platz das ganze Geraffel in meinem FS belegt, und das ist ’n ganz anderer Wert.

Benutzeravatar
TRex
Moderator
Beiträge: 8074
Registriert: 23.11.2006 12:23:54
Wohnort: KA

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

Beitrag von TRex » 27.07.2014 10:23:21

Für jemanden, der lieber mit einem Tool als mit Shell-Gefrickel arbeitet, vielleicht.
Wenigstens gibts unter Linux zu dem "Tool" keine gratis Toolbar, Norton 360 Trial, McAffee Scanner Trial, Flash und "free mp3 download" dazu :)
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 27.07.2014 10:46:09

niemand hat geschrieben:
Das Tool kann man ja auf dem Zielrechner mal schnell installieren. Den Shell-Einzeiler müsste man sich erst wieder irgendwo aus einer Know-how-Sammlung besorgen.
Und bei dem „Tool“ muss man dann noch schnell deine ewig lange Anleitung lesen, während man beim Einzeiler nur auf Enter zu drücken braucht.
Die Anleitung liest er nur einmal. Dann hat er es für den Rest seines Lebens verstanden. Die man-Page von 'ytree' ist so schlecht, dass ich ohne meinem ZTreeWin-Crash-Kurs-Wissen, das ich von einem Profi mündlich erhalten hatte, 'ytree' sofort wieder in die Ecke geschmissen hätte. Google mal nach 'ytree', und du wirst nichts vergleichbares im Netz finden. Die Anleitung war also meiner Meinung nach mal dringend nötig.
niemand hat geschrieben:Mir z.B. erschließt sich die praktische Relevanz nicht – für mich ist in dem Kontext eher wichtig zu wissen, wieviel Platz das ganze Geraffel in meinem FS belegt, und das ist ’n ganz anderer Wert.
Interessanter Gedanke. Aber, im Endeffekt hängt das Ganze jedoch von der Effizienz des jeweiligen File-Systems ab. Auf jedem System kriegst du dann für die gleichen Daten regelmäßig andere Größenangaben.

Auch das Thema ist wohl Geschmacksfrage: Die einen wollen es in Brutto wissen, die anderen in Netto.

In diesem Thread geht es ums Netto.

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 27.07.2014 11:07:02

Die Anleitung liest er nur einmal. Dann hat er es für den Rest seines Lebens verstanden.
Den Einzeiler tippt er auch nur einmal. Dann hat er ihn entweder in der History, oder er speichert ihn ab, oder er hat das Prinzip begriffen und kann ihn daher aus dem Kopf nachbauen.

Im Übrigen hat’s nicht viel mit der Effizienz eines FS zu tun. Wenn ein heutiges FS 4k-Blöcke hat, belegt eine 128B-Datei eben 4kB – sollte auch bei Win nicht viel anders sein.

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 27.07.2014 13:27:40

So, jetzt fällt mir gerade ein, warum mich meistens Netto und nicht Brutto interessiert:

Wenn ich Dateien von System A nach System B kopiere, will ich anschließend gucken, ob alles vollständig angekommen ist.

Bei besonders wichtigen Daten geh ich dann sogar mir MD5 und SHA1 drüber. Meistens reicht es aber, nachzusehen, ob auf
dem Zielsystem die gleiche Anzahl an Bytes angekommen ist.

Wer jetzt brutto rechnet, macht schon mal den ersten schwerwiegenden Fehler. Ich glaub, warum man da Netto statt Brutto nimmt, muss ich sicherlich niemandem erklären. Das versteht sich von selbst.

Zweitens ist es bei so einem Anwendungsfall eben auch wichtig, dass ich die Größen in Byte bekomme und nicht in Kilobyte.

Allerdings sieht mein praktischer Alltag so aus, dass ich meistens mit Daten deutlich kleiner als 1 Gigabyte zu tun habe. Und wenn ich doch Größenordnungen weit jenseits von 1 Gigabyte schaufle, dann arbeite ich mit Checksummen (MD5 / SHA1), weil bei meinen Rechnersystemen hin und wieder mal Bits umklappen, und ich das nur mit Hilfe von Checksummen bemerke. Gut, das wird langsam
offtopic.

Ich wollte nur noch schnell ein Beispiel liefern, warum das hier relevant ist.

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 27.07.2014 13:38:48

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
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 28.02.2016 11:07:52

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

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

Beitrag von geier22 » 28.02.2016 17:13:38

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

Code: Alles auswählen

 apt install k4dirstat
ergibt dann:

Bild

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 28.02.2016 17:20:34

… 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

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

Beitrag von geier22 » 28.02.2016 17:46:08

dolphin hat geschrieben: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
niemand hat geschrieben:… 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

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

Beitrag von DeletedUserReAsG » 28.02.2016 17:51:10

Ä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

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

Beitrag von geier22 » 28.02.2016 18:09:00

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

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

Beitrag von DeletedUserReAsG » 28.02.2016 18:19:05

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

dolphin
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 28.02.2016 20:30:57

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:
geier22 hat geschrieben: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
Beiträge: 362
Registriert: 01.05.2006 11:48:24

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

Beitrag von dolphin » 18.11.2018 16:39:36

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 ;-)

Antworten