Hi lieber Borlander,
"Interne Win-Dos"
Wenn Du noch DOS hast (bis einschließlich WinME), dann hast Du nicht die NT-Erweiterungen wie FOR zur Verfügung.
Die "FOR-IN-Schleife" funktioniert definitiv seit DOS-5.0 - WindowsXP MCE, sowohl in der sogenannten "MS-DOS-Eingabeaufforderung" (Win9X-XP) aus auch "Real-DOS-Modus" (Win3.1 - WinME), sowohl in "XX.Bat" oder per direkter Eingabe.
Wenn du "FOR_IN" direkt auf dem DOS-Promt, oder in der "MS-DOS-Eingabeaufforderung" ein gibst, lautet der Syntax:
--FOR %I IN (Quelle) DO Befehl %I --
Wenn du "FOR_IN" in einer "XX.Bat"-Datei ausführen willst, lautet der Syntax:
--FOR %%I IN (Quelle) DO Befehl %%I --
Die "Eingabeaufforderung" für NT-Basierte Win-Umgebungen, ist die CMD.EXE. Sie ist eine NT-Basierte Erweiterung für die Command.com. Wenn eine "XX.bat"-Datei aufgerufen wird, übergibt die CMD.exe die Befehle an die Command.com .
Die Command.com, hat auch in WinXP, heute noch die selben internen Befehle, wie Anno-Dazumal. Und genau hier liegt "der Hund begraben". Weil die Command.com noch für Zeiten programmiert war, als viel Rechen-Performance nicht vorhanden war, arbeitet sie ihre Befehle einzeln ab.
Du wirst weder unter DOS, noch in einem Win-System, eine Datei mit dem Namen copy.exe oder copy.com finden. Trotzdem kann jedes MS-OS copy ausführen; weil es ein "interner Befehl" des Befehlsinterpreters ist.
Du wirst aber in jedem MS-OS eine Datei mit Namen "Xcopy.exe", oder "Xcopy.com" finden. Xcopx ist ein sogenannter "Externer Befehl".
Xcopy wurde, wenn auch mit Grenzen etwas weiter entwickelt. Copy eben nicht. Xcopy kann Verzeichnisstrukturen kopieren, copy kann es nicht. Xcopy ist komfortabler, erfordert aber eine Dos-komforme Verzeichnisstruktur, und dazu gehört auch ein fehlerfreier Eintrag vom Stammverzeichnis, bis zu allen Dateien in allen Unterverzeichnissen und Dateien eines Datenträgers.
Copy (ist so alt), dass es diese "Ansprüche" nicht stellen kann.
Genau deshalb, ist copy immer dann vorzuziehen, wenn es strukturelle Probleme in Dateisystem gibt. .. gilt aber nur für FAT-Dateisysteme. Aber von Fat(32) wird ja gelesen...
-----
Du kannst das gerne Prüfen. Suche in einem NT-Basierten Win, nach command.com, cmd.exe, und xcopy.*
Soche in irgend einem MS-OS eine Datei "copy.*"
In WinXP befinden sich die "xcopy.exe, command.com. und cmd.exe" im Verzeichnis(Ordner) C:\Windows\System32.
In WinNT, 200X befinden sie sich in "C.\WINNT\System32.
Mach doch mal einen Test, und kreiere folgende Stapeldateien.
xtest.bat
xcopy D:\temp C:\temp
---
ctest.bat
copy D:\temp\*.* C:\temp
.... bei copy, muss das Verzeichnis C:\temp bereits existieren, wenn nicht, schlägt die Aktion fehl.
.....bei xcopy wird gefragt, wenn das Zielverzeichnis nicht existiert; bei copy nicht.
Dann benenne die Datei Xcopy.exe(oder .com) um in xcopy.bak
Schon wirst du merken, das copy auch ohne externe Dateien auskommt, während xcopy seit je her eine Datei braucht...
Wenn Du noch DOS hast (bis einschließlich WinME), dann hast Du nicht die NT-Erweiterungen wie FOR zur Verfügung.
Eine NT-Erweiterung wie FOR, ist mir vollkommen unbekannt.
FOR ist intern, in der Command.com eingebunden, seit mindestens DOS-5.0 bis WinXP MCE
Such Dir einfach mal die größte Datei raus die Du finden kannst, kopiere sie mit xcopy und behalte dabei die Speicherauslastung
Die Größe der größten Datei, spielt nur bedingt eine Rolle. Das Problem ist hier evtl. Die Anzahl der Dateien, die in einem FAT-Dateisystem sowohl in Anzahl als auch in Größe beschränkt sind. Auch die Anzahl der Verzeichnisnamen und Dateinamen, haben gerade bei Fat enge Grenzen. So weit ich weiß, Max 255 Zeichen vom Stammverzeichnis, bis zum letzten Dateinamenzeichen
Beim Einlesen einer Dateiliste, welche diese Beschränkungen "sprengt" werden "Error-Codes" zurückgemeldet. Ein Programm, das diese "Überschreitung der Grenzen" nicht merkt, weil es die Dateien einzeln abarbeitet, kann auch keine "Error-Codes" zurückgeben; genau hier liegt nämlich möglicher Weise der Knackpunkt.
Ich habe schon Gigabytes an Daten mit xcopy kopiert, da gibt es definitiv keine Probleme
..ob du mir es glaubst oder nicht. Ich auch, und zwar ohne Probleme.
Der Punkt ist nur, dass es meim "Kaptn" eben nicht geht; denn wenn es gehen würde, dann hätte er es mit dem Explorer rüber ziehen können, und dieses Brett wäre nie eröffnet worden.
Ich kenne seine Probleme, weil ich sie auch schon hatte. Ich arbeite heute noch teilweise mit einem 486er. Klar, wenn ich bei meinem Neuen so eine Scheiße hätte, würde ich ihn in die Tonne treten, meine Alten haben da schon mehr Kredit. :-)
Wenn das Dateisystem defekt ist, dann ist man mit einem Datenrettungstool sowieso besser beraten.
Dem würde ich sogar zustimmen. Aber du weißt, dass so ein Datenrettungstool auch ein gewisses Risiko darstellt, dass man alles verliert. Wenn mein Vorschlag nur eine gewisse Menge der Dateien in Sicherheit bringt, kann man das Datenrettungstool immernoch probieren. ...nur nach dem Motto: Doppelt hält besser. :-)
XCOPY /C erlaubt übrigens ein Fortsetzen nach aufgetretenen Fehlern.
Klar, xcopy is bequemer. Aber xcopy greift auf einen anderen Weg auf die Dateien zu als copy. Xcopy ist dafür ausgelegt, Verzeichnisstrukturen zu kopieren. Wenn in der Struktut ein Fehler ist, wird xcopy scheitern, genauso wie der Explorer.
Nehmen wir einmal an, die Dateien im Quellverzeichnis sind OK, aber der Eintrag der Summe der Dateien in der Verzeichnisliste ist fehlerhaft, würde Xcopy bei jedem Zugriff auf eine Datei im fehlerhaften Verzeichnis einen Fehler zurückgeben. Die option /C sagt zwar dass xcopy das gleiche mit der nächsten Datei versuchen soll, aber es würde wieder der selbe Fehler auftreten.
Copy ließt die "Verzeichnisbedingungen" nicht ein. Copy "greift" sich direkt eine Datei, kopiert sie, und speichert sie. Das OS schreibt dann diese einzelne Datei in die Liste des Zielverzeichnises. Danach wird die nächste Datei kopiert, usw. ...
... ich hoffe, lieber Bor, du bist mir jetzt nicht allzu böse, aber ich bin Überzeugt, dass mein Post nach bestem Wissen und Gewissen verfasst wurde, aus einem Bereich, in dem ich wirklich sehr viele persönliche Erfahrung gesammelt habe.
Erfahrung ist der beste Lehrmeister. :-)
Liebe Grüsse, Data Junkey
taste1984
KaptnFlint
Borlander
gelöscht_35042
Olaf19
