Wie am einfachsten 1000nde Dummy-Dateien (0 byte) erstellen?

Da gibt man sich so viel Mühe, sucht stundenlang einen passenden Interrupt und dann ist Dirck seit dem 29.9. nicht mehr online :D :eek:
 
:D


Ich hab bei C auch versagt :(
Ich krieg es einfach nicht hin, eine simple Zahl aus der Zählschleife in ein char-Arrays zu konvertieren :D
Strings gibts da nicht, das ist das Problem. Die gibts nur, wenn man sie extra implementiert und dann kommt die Methode, die Dateien erstellen kann, damit nicht klar. Ich kriegs zwar hin, Dateien zu erzeugen, aber dann nur so viele, wie ich Zeichen habe. Ich gehe dann nämlich nur alle 255 Zeichen durch, die char kennt, und die Zeichen, die nicht in den Datei-Namen können, werden ignoriert.

Fazit: Ich komme nicht mal auf 300 Dateien -.-

Wenn ich es aber schaffe, einen integer in ein char-Array zu konvertieren, dann kann ich beliebig viele Dateien erstellen, bis eben NTFS schlapp macht. Und ich würde wetten, das dauert kaum ein paar Sekunden, wenn ich bedenke, dass er die 200 und noch was Dateien noch innerhalb des selben Augenblicks erstellt hat, als ich das Programm gestartet habe. Die schwarze Konsole war bloß einen Bruchteil einer Sekunde offen und der Ordner war voll mit Dateien :D Die Geschwindigkeit von C finde ich einfach nur krass :D
 
Dev-C++

Und implementiert hab ich bisher die:
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <io.h>
#include <sys\stat.h>

Aber ich hab keine Ahnung, was ich da nun brauch :D
 
Hehe, noch ein Trick, in Verbindung mit bastlas Batchdatei eine Nullbyte-Datei zu erstellen. :D

Erzeuge zunächst eine Textdatei mit folgendem Inhalt und speichere sie mit z.B. dem Namen NullByte.dbg ab:
Code:
a
ret

rcx
1
nNullByte.com
w
q
Als nächstes bemühst du den uralten und immer noch vorhandenen DOS-Debugger mit folgendem Befehl auf der Kommandozeile:
debug < nullbyte.dbg


Nach Sekundenbruchteilen hat der dann ein ausführbares Programm namens NULLBYTE.COM erstellt, welches nur ein "return" enthält und absolut nichts macht. Dieses verschiebst du an eine Stelle im Suchpfad, z.B. C:\Windows, und ersetzt dann das "echo." im Batchskript damit:
nullbyte > %counter%
 
Über drei Umwege kann man es auch machen, hast Recht xD

Aber ich werd mich früher oder später nochmal mit C auseinander setzen und dann bau ich das noch zuende ^^
 
ot:
Ganz im Gegenteil - gar kein Umweg, da nur mit Betriebssystemmitteln, ohne dickem Compiler oder sonstigen 3rd-Party-Hilfen.
Macht man ein einziges Mal, dauert nur 1-2 Minuten, und schon hast du den echo.-Ersatz für immer und jede Batchdatei zur Verfügung. ;)
Mit dem nul-Device ginge das zwar auch (nul > dummy), ergibt aber leider eine Zugriffsverletzung wegen fehlender Rechte, da das ein virtuelles Systemgerät ist.
 
Na, gib ganz einfach mal in der Eingabeaufforderung nul > dummy ein.
Die Datei "dummy" wird zwar mit 0 Byte Größe erzeugt, es kommt aber auch o.a. Fehlermeldung und ist daher leider unbrauchbar.

Normalerweise wird das nul-Device ja auch nur für die Ausgabeumleitung ins Nirwana verwendet, wenn die Meldungen eines Programms nicht erscheinen sollen.
Also beispielsweise so: MeinProgrammErzähltWas > nul - So, jetzt erzählt es nix mehr.
 
Doof :/

Mir fällt aber grad auch kein Weg ein, wie man das unterdrücken kann.


Aber wenn man mit deinem kleinen Zusatz 0 Byte-Dateien erstellen kann, dann kann man ja auch nur mit Hilfe von Batch das ganze lösen, da auch Batch die Möglichkeit bietet, das OS abzufragen. Zwar leider nur im Windows, aber um das zu umgehen, braucht man nun mal eine Hochsprache, die mit verschiedenen Umgebungen umgehen kann.


Edit:
Mir fällt grad ein, dass das OS ja nix bringt :D
Mal schauen, ob es da nicht eine Möglichkeit gibt, oder ob ich schau, wie ich mit C eine kleine exe erstellen kann, die das Datei-System angibt.
 
Zuletzt bearbeitet:
@Norbert: Was ist das denn für eine uralte Programmiersprache mit einem DOS-Compiler :D?
Die kenne ich ja noch gar nicht - kannst du das Script mal erklären, also was z. B. "rcx" oder "w" oder "q" macht :D?

ot:
Der Thread hat hier schon 600 Hits :eek::D
 
Kein Compiler, sondern nur ein Debugger und Mini-Assembler. :D
Ist schon seit den Anfängen von MS-DOS mit dabei. Wenn man damit umgehen kann, ist dieses kleine Tool recht leistungsfähig.
Das "Skript" ist gar keins, sondern der (fast) echte Quellcode eines Assembler-Programms.
"Fast" deswegen, weil ein richtiger Assembler ganz andere und viel mehr Steuerbefehle kennt.

Die wichtigsten und häufigsten Steuerbefehle von debug.exe:
  • a = Assemble, Start eines Blocks mit Assembler Mnemonics.
    Der Block muss mit einer Leerzeile beendet werden, damit wieder die Steuerbefehle aktiv werden.
  • r = Register laden, hier cx mit dem Wert 1
  • n = Name der erzeugten Datei
  • w = Write, Datei schreiben, es wird die zuvor in bx:cx geladene Anzahl an Bytes geschrieben.
  • q = Quit, Debugger beenden

Wichtiger Unterschied zum vollwertigen Assembler: Zahlen ohne "h" am Ende werden als hexadezimale Werte interpretiert.
Siehe auch die Befehlsreferenz: MS-DOS DEBUG Program.
Hier noch ein kleiner Workshop.
 
Zuletzt bearbeitet:
Herzlichen Dank für Eure Hilfe,

auch für das Skript, bastla, funktioniert einwandfrei, um schnell und einfach viele Dateien zu erzeugen, kann ich gut gebrauchen.

Der Vorteil bei robocopy wäre ja, daß man sogar Dummy-Dateien identischen Dateinamens wie die der Dateien aus einem gewünschten Ordner erzeugen konnte, so daß man die nachträgliche Umbenennung hätte auslassen können, wenn es funktioniert hätte.

Vielen Dank nochmals.
 
Oben