Datei definierter Länge in Windows erzeugen

[vergesslicher Typ (Gast)]

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?

[Udo S. (urschmitt)]

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(...

[Krapao (Gast)]

Create a new file of a specific size

    FSUTIL file createnew filename

    Eg : fsutil file createnew C:\testfile.txt 1000

[vergesslicher Typ (Gast)]

Danke! FSUTIL hat wie gewünscht funktioniert.

[Reinhard Kern (Gast)]

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

[FileWriter (Gast)]

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

[oszi40 (Gast)]

>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 ?

[Peter II (Gast)]

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.

[Rolf Magnus (Gast)]

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.

[Läubi .. (laeubi)]

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

[Reinhard Kern (Gast)]

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

[Reinhard Kern (Gast)]

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

[Rolf Magnus (Gast)]

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.

[oszi40 (Gast)]

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.