Hallo Freunde,
echo > test.txt zu erstellen ist einfach.
Zu Testzwecken brauche ich nun leere Dateien mit definierter Länge.
Leider habe ich meinen Zettel verlegt. Go*gle fand ihn auch nicht
gleich.:-)
Es gab unter Windows eine Möglichkeit per Befehl eine Datei BESTIMMER
Größe zu erstellen. Wie war der?
Es gibt keine leere Datei mit einer Länge > 0
Irgendwas steht immer drin.
Wie du das mit Kommandozeilenmittel erzeugst weiß ich nicht aber mit 10
Zeilen C gehts ganz einfach
fp = fopen(...
for (i=0; ...
{
fputs(..
}
fclose(...
Udo Schmitt schrieb:> Es gibt keine leere Datei mit einer Länge > 0
Das stimmt so nicht, siehe:
http://de.wikipedia.org/wiki/Sparse-Datei
Die Frage ist natürlich, was man genau unter leer versteht, aber es gibt
jedenfalls Dateien, die möglicherweise GB gross sind und keinen Platz
verbrauchen.
Gruss Reinhard
Reinhard Kern schrieb:> aber es gibt> jedenfalls Dateien, die möglicherweise GB gross sind und keinen Platz> verbrauchen.
Stichwort: "Sparse Files":
http://www.ntfs.com/ntfs-sparse.htm
"keinen Platz verbrauchen" ist allerdings eine etwas "überoptimitische
Grobabschätzung"...
;-)
MfG
>fast "keinen Platz verbrauchen"
Nach meiner Kenntnis "Sparse Files" nur bei NTFS5, aber nicht bei FAT.
Im Falle einer Komprimierung wie zip kann aus einem Sack voller Nullen
auch eine sehr kleine Datei werden.
Wenn man davon ausgeht, daß bei dem einfachen Löschen einer Datei nur
das Direktory markiert wird, bleibt noch ein bunte Mischung Buchstaben
auf den Sektoren der HD übrig, die beim Ziehen eines KOMPLETTEN Images
viel Platz braucht. Wenn stattdessen eine große Datei mit lauter 11111
stünde, würde das komprimierte Image viel kleiner werden. Habt Ihr da
Tricks ?
Udo Schmitt schrieb:> Zeilen C gehts ganz einfach>> fp = fopen(...> for (i=0; ...> {> fputs(..> }> fclose(...
das ist weder einfach nocht schnell. man springt einfach mit seek an die
neue Dateigröße und das wars.
oszi40 schrieb:> Wenn man davon ausgeht, daß bei dem einfachen Löschen einer Datei nur> das Direktory markiert wird, bleibt noch ein bunte Mischung Buchstaben> auf den Sektoren der HD übrig, die beim Ziehen eines KOMPLETTEN Images> viel Platz braucht. Wenn stattdessen eine große Datei mit lauter 11111> stünde, würde das komprimierte Image viel kleiner werden. Habt Ihr da> Tricks ?
Genau diese große Datei anlegen, so daß sie den kompletten Rest des
Dateisystems belegt, dann wieder löschen. Dann ist danach die
überwiegende Mehrheit der unbelegten Sektoren nicht mehr "bunt".
Alternativ einfach partclone oder halt clonezilla nehmen. Das kennt das
Filesystem und schreibt ins Image nur die Teile, die auch tatsächlich
als benutzt marktiert sind, unabhängig von deren Inhalt. Das geht auch
schneller, wenn die Partition nicht ganz voll ist.
oszi40 schrieb:> Wenn man davon ausgeht, daß bei dem einfachen Löschen einer Datei nur> das Direktory markiert wird, bleibt noch ein bunte Mischung Buchstaben> auf den Sektoren der HD übrig, die beim Ziehen eines KOMPLETTEN Images> viel Platz braucht. Wenn stattdessen eine große Datei mit lauter 11111> stünde, würde das komprimierte Image viel kleiner werden. Habt Ihr da> Tricks ?http://technet.microsoft.com/en-us/sysinternals/bb897443
FileWriter schrieb:> "keinen Platz verbrauchen" ist allerdings eine etwas "überoptimitische> Grobabschätzung"...
wär ich mir nicht so sicher - ich habe nicht probiert, ob man eine Datei
erstellen kann, die nur Sparse-Daten enthält - die müsste dann melden
"Dateigrösse 10 GB, auf dem Datenträger 0 kB". Das würde sicher manchen
User verunsichern, besonders bei Kopierversuchen.
Gruss Reinhard
oszi40 schrieb:> Wenn stattdessen eine große Datei mit lauter 11111> stünde, würde das komprimierte Image viel kleiner werden. Habt Ihr da> Tricks ?
Die einzig zuverlässige Lösung ist meiner Meinung nach ein
Backup-Programm, das das Dateisystem versteht und unbenutzte Teile der
Partition garnicht erst sichert. Dem steht v.a. unter Unix die Vielfalt
von Dateisystemen im Weg, mit FAT und NTFS gibt es eher kein Problem.
Gruss Reinhard
Reinhard Kern schrieb:> Dem steht v.a. unter Unix die Vielfalt von Dateisystemen im Weg, mit FAT und> NTFS gibt es eher kein Problem.
Mit clonezilla kommt man eigentlich gut aus, wenn man nicht gerade was
exotisches nimmt:
> Filesystem supported:> (1) ext2, ext3, ext4, reiserfs, reiser4, xfs, jfs of GNU/Linux,> (2) FAT, NTFS of MS Windows,> (3) HFS+ of Mac OS,> (4) UFS of FreeBSD, NetBSD, and OpenBSD, and> (5) VMFS3/4 of VMWare ESX.>> Therefore you can clone GNU/Linux, MS windows, Intel-based Mac OS, and FreeBSD,> NetBSD, and OpenBSD, no matter it's 32-bit (x86) or 64-bit (x86-64) OS. For> these file systems, only used blocks in partition are saved and restored.
Clonezilla ist schon gut. Wenn es ratlos ist, sichert es automatisch per
DD bitweise "jeder Fliegendreck" mit. Dann brauchen natürlich die bunten
Sektoren komprimiert mehr Platz als eine große Datei mit alles 0000.
Eine eigene Frage?
Dieser Thread ist über 15 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.