Grösse anders nach Kopiervorgang

[Trollkirsche]

Hallo zusammen,

Irgendwie kann ich mir das nicht erklären:

Wenn ich eine Kopie eines Ordners erstelle, ändert sich die Grösse des Ordners. Erst habe ich den Ordner in das gleiche Verzeichnis und somit dem gleichen Dateisystem kopiert.
Die Anzahl Dateien war diesselbe doch die Grösse des Ordners war unterschiedlich. Ich hab dann den PC neu gestartet und anstelle über den Desktop, mit cp -a gearbeitet. Danach war die Grösse die gleiche wie der Originalordner.

Jetzt habe ich den Ordner auf meinen Server kopiert. Hier genau das gleiche, die Grösse des Ordners ändert sich, obwohl es sich bei beiden um ext4 Dateisysteme handelt.

Der Originalordner hat : 83.0 GB (82’983’172’968 Bytes)
Die Kopie auf dem Server hat : 83.0 GB (82’983’226’216 Bytes)

Warum ist das so? Das stresst mich grad sehr, denn wie will ich so gewährleisten, dass die Daten integer sind?

Gibt es eine Möglichkeit herauszufinden, welche Dateien sich exakt von der Grösse zum Originalordner unterscheiden, damit dem mehr nachgegangen werden kann?

Danke,

[hikaru]

Du könntest einen Dry-Run mit rsync zwischen beiden Ordnern machen:

Code: Alles auswählen

rsync --size-only --dry-run ORIGINAL/ KOPIE/

[Livingston]

Ich nehme an, dass die Abweichungen nichts mit den Dateigrößen, sondern mit der Struktur der Verzeichnisse zu tun hat. Z.B. besteht ein ext4-System aus einer ziemlich ausgefeilten Baumstruktur. Je nachdem, ob ein Verzeichnis in einzelnen Schritten historisch gewachsen oder komplett neu angelegt wurde, können sich diese Bäume geringfügig unterscheiden. D.h. der Platzbedarf der Verwaltungsstrukturen ist unterschiedlich, nicht der verwaltete Inhalt.

[Trollkirsche]

Ich nehme an, dass die Abweichungen nichts mit den Dateigrößen, sondern mit der Struktur der Verzeichnisse zu tun hat. Z.B. besteht ein ext4-System aus einer ziemlich ausgefeilten Baumstruktur. Je nachdem, ob ein Verzeichnis in einzelnen Schritten historisch gewachsen oder komplett neu angelegt wurde, können sich diese Bäume geringfügig unterscheiden. D.h. der Platzbedarf der Verwaltungsstrukturen ist unterschiedlich, nicht der verwaltete Inhalt.

Das heisst ich kann trotzdem davon ausgehen, dass die die Dateien ordnungsgemäss kopiert wurden und somit die Daten integer sind?

[tobo]

Gibt es eine Möglichkeit herauszufinden, welche Dateien sich exakt von der Grösse zum Originalordner unterscheiden, damit dem mehr nachgegangen werden kann?

Ist zwar eigentlich für Text gedacht, sollte aber funktionieren:

Code: Alles auswählen

diff -qr dir1 dir2

[Trollkirsche]

Gibt es eine Möglichkeit herauszufinden, welche Dateien sich exakt von der Grösse zum Originalordner unterscheiden, damit dem mehr nachgegangen werden kann?

Ist zwar eigentlich für Text gedacht, sollte aber funktionieren:

Code: Alles auswählen

diff -qr dir1 dir2

Ich führ den Befehl grad aus, mal schauen was sich ergibt.

Danke euch allen!

[Trollkirsche]

Hallo,

der diff -qr Befehl hat folgendes ergeben:

diff -qr srcdir destdir
diff: /skyrimse/dosdevices/c:/windows/syswow64/d3d12.dll: Datei oder Verzeichnis nicht gefunden
diff: /dosdevices/c:/windows/syswow64/d3d12.dll: Datei oder Verzeichnis nicht gefunden
diff: /dosdevices/f::: Datei oder Verzeichnis nicht gefunden
diff: /dosdevices/f::: Datei oder Verzeichnis nicht gefunden
diff: /dosdevices/h::: Datei oder Verzeichnis nicht gefunden
diff: /dosdevices/h::: Datei oder Verzeichnis nicht gefunden
diff: /drive_c/windows/syswow64/d3d12.dll: Datei oder Verzeichnis nicht gefunden
diff: /drive_c/windows/syswow64/d3d12.dll: Datei oder Verzeichnis nicht gefunden

Es gibt also schon einen Unterschied. Ich habe den Pfad aus Privatsphäre gelöscht. Es handelt sich um ein WinePrefix eines gemoddeten Skyrim.
Wieso wurde die Datei "d3d12.dll" nicht mitkopiert? Und was bedeuten die f:::, h::: Einträge?

Das finde ich alles grad ziemlich space...

edit : Ich habe den destination syswow64 Ordner überprüft, die Datei ist komischerweise vorhanden...

find ./ -name d3d12.dll
./d3d12.dll

Ich habe mir die Datei d3d12.dll mal näher angeschaut. Das ist eine Verknüpfung, die auf den Ordner lutris zeigt : /home/benutzer/.local/share/lutris/runtime/dxvk/v1.9.1L/x32/d3d12.dll
Dann gibt es noch eine Datei d3d12.dll.orig?

Ist das normal? Warum befindet sich dort nicht direkt die Datei "d3d12.dll" und stattdessen eine Verknüpfung?


Gruss,

[Livingston]

Oder ein Rechte-/Besitzproblem? Gehören vielleicht einzelne Dateien einem anderen User / einer anderen Gruppe?
Was ergibt, wenn Du diff als root darauf loslässt?

NACHTRAG: Du könntest auf der richtigen Spur sein. Wenn die nicht die Links übernommen werden, sondern die Dateien dahinter vollständig kopiert werden, macht das natürlich einen Größenunterschied aus.

[Trollkirsche]

Oder ein Rechte-/Besitzproblem? Gehören vielleicht einzelne Dateien einem anderen User / einer anderen Gruppe?
Was ergibt, wenn Du diff als root darauf loslässt?

NACHTRAG: Du könntest auf der richtigen Spur sein. Wenn die nicht die Links übernommen werden, sondern die Dateien dahinter vollständig kopiert werden, macht das natürlich einen Größenunterschied aus.

Bei der source wie auch destination dir sind diesselben Dateien, namentlich eine d3d12.dll als Link und eine d3d12.dll.orig.
Die Grösse des Ordners unterscheidet sich jedoch. Das Problem muss aber mit der d3d12.dll zusammenhängen, so wie ich das sehe.

Ich hab mir noch einen anderen WinePrefix Ordner angeschaut und dort gibts keinen Link zum lutris Ordner, aber eine d3d12.dll Datei. Ich hab kurzerhand den Link und die .orig im Skyrim Wineprefix gelöscht und die d3d12.dll Datei vom anderen Wineprefix in den syswow64 Skyrim Ordner rüberkopiert.

Normalerweise müsste jetzt die grösse beim Kopieren diesselbe sein. Ich geb euch Bescheid.

[Trollkirsche]

Ich hab jetzt die d3d12.dll Datei kopiert und eigentlich müsste der Ordner gleich gross sein?

Ist er aber leider nicht:

Src : 83.0 GB (82’983’307’951 Bytes)
Dest : 83.0 GB (82’983’361’199 Bytes)

Im Verzeichnis DosDevices im Wineprefix befinden sich noch zwei Dateien:
f:: und h::

Was hat es mit diesen Dateien auf sich? Das scheinen ebenfalls Linkverweise zu sein und wenn ich sie Doppelklicke erhalte ich die Fehlermeldung:
Die Verknüfpung >>>f::<< ist fehlerhaft. Soll sie in den Papierkorb verschoben werden?
Diese Verknüpfung kann nicht verwendet werden, da ihr Ziel >>/dev/sr0<< nicht existiert.

Dann gibt es noch ein Verzeichnis z:. Dieses Verzeichnis wiederum zeit auf mein / root Verzeichnis...

Das wird dann ja nicht mitkopiert.

Das will mir irgendwie nicht in den Kopf...

[Trollkirsche]

Was meint ihr? Soll ich alles nochmal neu anfangen oder kann ich beruhigt weiter modden ?

Müsste normalerweise bei einer Verknüpfung nicht einfach diese auch mitkopiert werden?

[Livingston]

Kann ich pauschal nicht beantworten. Auch was wine da genau mit Partitionsbezeichnern wie f: oder h: anstellt, weiß ich leider nicht.
Aber es gibt noch eine mögliche Ursache für die Abweichungen: Sog. Sparsedateien, sprich Dateien, die aus vielen Nullen bestehen, aber nicht in voller Länge gespeichert werden. Die "Löcher" werden quasi ausgespart, es wird nur intern vermerkt, wo die Lücken mit Wert 0 auftauchen. Im Ergebnis spart man dadurch eine Menge Platz. Wenn man sie ausliest, erhält man am Ende wieder die volle Länge. Such mal in der manpage zum Befehl cp nach dem Stichwort "sparse".

[DaCoda]

Also als erstes solltest du dir über folgende Dinge im Klaren sein:
- Es gibt symbolische Links und hard Links unter Linux. Symbolische Links verweisen auf eine andere Datei. Bei hard Links hat eine Datei quasi zwei Dateinamen. Des weiteren gibt es .desktop Dateien unter Linux und .lnk unter Windows (was aber relativ uninteresant ist, da es normale Dateien sind). Unter Windows/NTFS gibt es möglicherweise noch andere Sachen wie zB Junctions.
- Oft (zB beim Befehl du ohne weitere Optionen) wird der Platzverbrauch auf der Festplatte angezeigt und nicht die Größe des Inhalts der Dateien. Deshalb kann bei der Kopie eines Ordners etwas anderes herauskommen. ZB kann eine Datei auf der Festplatte 4kb belegen obwohl der Inhalt nur 1 byte lang ist.

Du musst dir vorher überlegen:
- Willst du Symlinks mitkopieren? Sollen die Kopie-Symlinks auf den Quellordner zeigen oder auf die Kopie?
- Willst du Berechtigungen mitkopieren?
- Hat das Ziellaufwerk womöglich ein anderes Dateisystem, so dass Zeitstempel nicht mehr exakt gleich sind? FAT32 Zeitstempel haben eine Genauigkeit von 2 Sekunden. Wenn du also zB von ext4 nach FAT32 kopierst, ändern sich die Zeitstempel. Dann denken Backup-Programme wie z.B. rsync, dass Dateien verschieden sind, obwohl sie gleich sind. Dafür gibt es dann aber bei rsync --modify-window.

Wenn ich meinen Home-Ordner auf ext4 sichere, verwende ich immer rsync. Das lässt Symlink standardmäßig komplett weg. Wenn ich bei Windows einen Ordner auf USB sichere, nehme ich auf dem USB-Stick immer exfat. Das kann nämlich keine Symlinks und somit kann mich dann auch nichts durcheinander bringen.

Du musst dir halt vorher im Klaren sein, wie dein Kopierprogamm symbolische Links behandelt.

Wenn diff sagt, dass die Datei nicht gefunden wurde, verweist ein symbolischer Link auf eine nicht existierende Datei. Wenn diff sonst nichts ausgibt, außer solchen Meldungen, ist eigentlich alles identisch bis auf (eventuell) die Symlinks.

Soweit ich sehe hast du Windows-Dateien gesichert (z.B. /drive_c/windows/syswow64/d3d12.dll). Generell ist zu sagen, dass wenn du von NTFS zu ext4 sicherst, gewisse Informationen verloren gehen. Vor allem die ACLs gehen verloren und es gibt bei Windows zB Junctions, welche auf ext4 nicht abgebildet werden können (oder zu symlinks konvertiert werden). Eventuell ist auch die Auflösung des Zeitstempels nicht die gleiche. Um private Dateien zu sichern ist ext4 natürlich geeignet. Aber nicht um die Windows-System-Dateien später wieder auf das NTFS-Laufwerk zu kopieren um davon zu booten.

Wenn du also dein Windows-Laufwerk auf ext4 sichern willst, verwende rsync. Dann werden die nervigen symlinks/junctions erst gar nicht kopiert. Das reicht um private Dateien zu sichern.

Wenn du ein Windows-Laufwerk sichern willst und auch später zB von der Sicherung booten willst, musst du dd verwenden um ein image zu erzeugen. zB dd if=/dev/sda of=blub bs=4M status=progress

Also lösche am besten alle Symlinks aus deiner Datensicherung (wenn du die nicht brauchst). Und dann lass rsync --dry-run (vergleicht modification date und Dateigröße) drüberlaufen oder wenn du ganz sicher sein willst diff (vergleicht Inhalt).

Wenn du nur die größe aller Dateien bestimmen willst, kannst du das zB mit folgendem PHP-Skript machen. Es berechnet für Symlinks und die Ordner selbst nichts.

Code: Alles auswählen

<?php
if (count($argv) != 2)
  die("Bitte exakt ein Argument angeben.\n");
if (!is_dir($argv[1]))
  die("Bitte einen Ordner angeben.\n");
function sumsize($p)
{
  $o = opendir($p);
  $size = 0;
  while (($r = readdir($o)) !== false)
  {
    if ($r == "." || $r == ".." || is_link("$p/$r"))
      continue;
    if (is_dir("$p/$r"))
      $size += sumsize("$p/$r");
    else if (is_file("$p/$r")) // Es gibt tatsaechlich Dateien die weder Links, Dateien, noch Ordner sind.
      $size += filesize("$p/$r");
  }
  closedir($o);
  return $size;
}

echo "total size: ".sumsize($argv[1])."\n";

Auszuführen wie folgt:

Code: Alles auswählen

sudo apt-get install php-cli
php sumsize.php "/path/to folder"

Damit müsste für den Quell- und Zielordner exakt das gleiche rauskommen.

[Trollkirsche]

Also als erstes solltest du dir über folgende Dinge im Klaren sein:
- Es gibt symbolische Links und hard Links unter Linux. Symbolische Links verweisen auf eine andere Datei. Bei hard Links hat eine Datei quasi zwei Dateinamen. Des weiteren gibt es .desktop Dateien unter Linux und .lnk unter Windows (was aber relativ uninteresant ist, da es normale Dateien sind). Unter Windows/NTFS gibt es möglicherweise noch andere Sachen wie zB Junctions.
- Oft (zB beim Befehl du ohne weitere Optionen) wird der Platzverbrauch auf der Festplatte angezeigt und nicht die Größe des Inhalts der Dateien. Deshalb kann bei der Kopie eines Ordners etwas anderes herauskommen. ZB kann eine Datei auf der Festplatte 4kb belegen obwohl der Inhalt nur 1 byte lang ist.

Du musst dir vorher überlegen:
- Willst du Symlinks mitkopieren? Sollen die Kopie-Symlinks auf den Quellordner zeigen oder auf die Kopie?
- Willst du Berechtigungen mitkopieren?
- Hat das Ziellaufwerk womöglich ein anderes Dateisystem, so dass Zeitstempel nicht mehr exakt gleich sind? FAT32 Zeitstempel haben eine Genauigkeit von 2 Sekunden. Wenn du also zB von ext4 nach FAT32 kopierst, ändern sich die Zeitstempel. Dann denken Backup-Programme wie z.B. rsync, dass Dateien verschieden sind, obwohl sie gleich sind. Dafür gibt es dann aber bei rsync --modify-window.

Wenn ich meinen Home-Ordner auf ext4 sichere, verwende ich immer rsync. Das lässt Symlink standardmäßig komplett weg. Wenn ich bei Windows einen Ordner auf USB sichere, nehme ich auf dem USB-Stick immer exfat. Das kann nämlich keine Symlinks und somit kann mich dann auch nichts durcheinander bringen.

Du musst dir halt vorher im Klaren sein, wie dein Kopierprogamm symbolische Links behandelt.

Wenn diff sagt, dass die Datei nicht gefunden wurde, verweist ein symbolischer Link auf eine nicht existierende Datei. Wenn diff sonst nichts ausgibt, außer solchen Meldungen, ist eigentlich alles identisch bis auf (eventuell) die Symlinks.

Soweit ich sehe hast du Windows-Dateien gesichert (z.B. /drive_c/windows/syswow64/d3d12.dll). Generell ist zu sagen, dass wenn du von NTFS zu ext4 sicherst, gewisse Informationen verloren gehen. Vor allem die ACLs gehen verloren und es gibt bei Windows zB Junctions, welche auf ext4 nicht abgebildet werden können (oder zu symlinks konvertiert werden). Eventuell ist auch die Auflösung des Zeitstempels nicht die gleiche. Um private Dateien zu sichern ist ext4 natürlich geeignet. Aber nicht um die Windows-System-Dateien später wieder auf das NTFS-Laufwerk zu kopieren um davon zu booten.

Wenn du also dein Windows-Laufwerk auf ext4 sichern willst, verwende rsync. Dann werden die nervigen symlinks/junctions erst gar nicht kopiert. Das reicht um private Dateien zu sichern.

Wenn du ein Windows-Laufwerk sichern willst und auch später zB von der Sicherung booten willst, musst du dd verwenden um ein image zu erzeugen. zB dd if=/dev/sda of=blub bs=4M status=progress

Also lösche am besten alle Symlinks aus deiner Datensicherung (wenn du die nicht brauchst). Und dann lass rsync --dry-run (vergleicht modification date und Dateigröße) drüberlaufen oder wenn du ganz sicher sein willst diff (vergleicht Inhalt).

Wenn du nur die größe aller Dateien bestimmen willst, kannst du das zB mit folgendem PHP-Skript machen. Es berechnet für Symlinks und die Ordner selbst nichts.

Code: Alles auswählen

<?php
if (count($argv) != 2)
  die("Bitte exakt ein Argument angeben.\n");
if (!is_dir($argv[1]))
  die("Bitte einen Ordner angeben.\n");
function sumsize($p)
{
  $o = opendir($p);
  $size = 0;
  while (($r = readdir($o)) !== false)
  {
    if ($r == "." || $r == ".." || is_link("$p/$r"))
      continue;
    if (is_dir("$p/$r"))
      $size += sumsize("$p/$r");
    else if (is_file("$p/$r")) // Es gibt tatsaechlich Dateien die weder Links, Dateien, noch Ordner sind.
      $size += filesize("$p/$r");
  }
  closedir($o);
  return $size;
}

echo "total size: ".sumsize($argv[1])."\n";

Auszuführen wie folgt:

Code: Alles auswählen

sudo apt-get install php-cli
php sumsize.php "/path/to folder"

Damit müsste für den Quell- und Zielordner exakt das gleiche rauskommen.

Vielen herzlichen Dank für deine exzellente Unterstützung!

Windows habe ich schon seit Jahren verbannt. Es handelt sich hierbei um Wineprefixes, die für die Ausführung von Windows Applikationen oder Windows Spielen benötigt werden. Unter DosDevices befindet sich dann unter anderem Linkverweise auf das Linux System.

Kopiert habe ich den Ordner über den Desktop. Meine Backups über das NAS lege ich ebenfalls immer per rsync an. Bisher habe ich jedoch für die Kopie eines Ordners auf dem gleichen System den "cp -a" Befehl verwendet oder gleich die Kopierfunktion der Desktop UI.

Ich nutze ausschliesslich nur noch ext4 auf allen Systemen. NTFS habe ich nicht mehr im Einsatz.

Werden beim Kopieren über den Linux Dateimanager nicht auch die Rechte mitkopiert?

Soll ich zukünftig ebenfalls immer auf rsync setzen wenn ich eine Kopie eines Ordners auf dem gleichen System und gleiche Partition durchführe um auf der sicheren Seite zu sein?
Ist der "cp -a" Befehl einer Kopie über die UI vorzuziehen?

[Trollkirsche]

Kann ich pauschal nicht beantworten. Auch was wine da genau mit Partitionsbezeichnern wie f: oder h: anstellt, weiß ich leider nicht.
Aber es gibt noch eine mögliche Ursache für die Abweichungen: Sog. Sparsedateien, sprich Dateien, die aus vielen Nullen bestehen, aber nicht in voller Länge gespeichert werden. Die "Löcher" werden quasi ausgespart, es wird nur intern vermerkt, wo die Lücken mit Wert 0 auftauchen. Im Ergebnis spart man dadurch eine Menge Platz. Wenn man sie ausliest, erhält man am Ende wieder die volle Länge. Such mal in der manpage zum Befehl cp nach dem Stichwort "sparse".

Damit muss ich mich mal etwas näher beschäftigen. Danke für den Hinweis!