Pfad zu lang ...

[Ulrich F. Heidenreich]

Guten Morgen!

Mein unterm Win95 liegendes DOS - deshalb die Frage hier - beglückte
mich heute am Ende eines XCOPY-Batchruns mit der Meldung

|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da der
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

UND WELCHER, HERR GATES? Das könnte man doch einfach melden, newa?

Und jetzt, wo mein Adrenalinspiegel inzwischen wieder auf verträgliche
Werte unten ist: Habe ich irgendeine Chance, die Übeltöterdatei anders
zu finden, als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um den
Zielordnernamen ergänzt ein Längenlimit überschritten hat?

TIA,
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um
den Zielordnernamen ergänzt ein Längenlimit überschritten hat?

Mach ein
dir /b /on /s * > List.txt
in der Wurzel Deines Baumes. Dann siehst Du recht mühelos, welches die
längsten Zeilen sind.

Axel

[Axel Berger]

Post by Axel Berger
dir /b /on /s * > List.txt

Da fehlt ein /x in den Optionen, Du willst hier die kurzen Dateinamen.
Für die langen gilt iirc die 256-Byte-Grenze nicht.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Axel Berger
dir /b /on /s * > List.txt

Da fehlt ein /x in den Optionen, Du willst hier die kurzen Dateinamen.

Nein. Wieso?

Post by Axel Berger
Für die langen gilt iirc die 256-Byte-Grenze nicht.

Ich kopiere aber die langen. Und auch dort gibt es wohl diese
Längenbegrenzung. Aber all das ist ja nicht das Problem, sondern
herauszufinden, welche Dateien XCOPY nicht kopierte, weil sie einen
zu langen Pfad am Ziel ergeben würden. Irgendwann möchte ich die
Quelle nämlich mal löschen und verständlicherweise vorher wissen,
welche Dateien nicht "drüben" sind.

Mhh. Bevor ich's selbst ausprobiere. Q: sei die Quelle, Z: das
Ziel, Qback der Pfad, in dem die Quelle - leider nicht komplett
- via XCOPY Q:\*.* Z:\Qback /s landete. Wäre ein

Dir Q:\*.* /b /on /s > quelldir.txt
Z:
CD Qback
Dir *.* /b /on /s > zieldir.txt
fc quelldir.txt zieldir.txt

ein möglicher Ansatz? Oder scheitert fc an/ab der Stelle, an/ab der die
beiden Directorylistings wegen fehlendem Zielsdatei-Eintrag nicht mehr
"synchron" sind?

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
Ich kopiere aber die langen. Und auch dort gibt es wohl diese
Längenbegrenzung.

Meines Wissens nicht. Xcopy kopiert zwar die langen Dateinamen auch,
arbeitet selbst aber allein mit den kurzen. Und wenn für lange
Dateinamen eine so kleine Grenze gälte, wären Probleme sehr viel
häufiger. Aber probier im Zweifel halt beides.

Post by Ulrich F. Heidenreich
sondern
herauszufinden, welche Dateien XCOPY nicht kopierte, weil sie einen
zu langen Pfad am Ziel ergeben würden.

Ja, genau dazu hilft Dir die Liste ja. Du könntest zum Beispiel in einem
Editor von allen Zeilen die linken 200 Spalten abschneiden. Es sollten
nur einige wenige nicht leere übrigbleiben. Oder noch exakter, Du
änderst im Editor in allen Zeilen vom alten auf den neuen Pfad und
suchst nach einem beliebigen Zeichen in Spalte 256. Alles, was dabei
gefunden wird, ist zu lang. Was mehr kannst Du noch wollen?

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger
Ja, genau dazu hilft Dir die Liste ja. Du könntest zum Beispiel in einem
Editor von allen Zeilen die linken 200 Spalten abschneiden. Es sollten
nur einige wenige nicht leere übrigbleiben. Oder noch exakter, Du
änderst im Editor in allen Zeilen vom alten auf den neuen Pfad und
suchst nach einem beliebigen Zeichen in Spalte 256. Alles, was dabei
gefunden wird, ist zu lang. Was mehr kannst Du noch wollen?

Dies nicht bei jedem XCOPY erneut veranstalten zu müssen, sondern einen
Batch bauen, eine Befehlsfolge finden bei dem/der unten die Information
"rausfällt", die mir der XCOPY-Befehl verweigert: Nämlich nicht nur,
*daß* einige Dateien nicht kopiert wurden, sondern *welche* nicht.

CU!
Ulrich

[Ulrich F. Heidenreich]

Post by Axel Berger
Ja, genau dazu hilft Dir die Liste ja. Du könntest zum Beispiel in einem
Editor von allen Zeilen die linken 200 Spalten abschneiden.

Die gesamte Liste des Quell-Laufwerkes bekomme ich in keinen Editor,
Notepad/Wordpad kann ich ganz knicken. Aber auch FileEdit schmiert
sofort ab; Word rödelt sich dabei die Füße solange wund, bis daß das
Win95 "Out of Ressources" ist.

Mühsam nährt sich das Eichhörnchen. Eher per Zufall bin ich jetzt auf

|Q:\Mail&News Downloads bis 1.2012\trpix.gif_kid=139269&bid=548075&iid=288985&uid=1&bls3=000000U&dlv=191,12854,288985,139269,548075&dmn=pD9FD8B19.dip.t-dialin.net&sta=,,,,,,,,,,0,0,0,283,281,1228,11,0&rdm=2591.724276642303&scx=1024&scy=768&scc=32&jav=1

gestoßen.

Ob's der einzige Kandidat war, wird sich nach Löschen desselben - dürfte
ein verseuchter Mailanhang gewesen sein und kann wech - zeigen. Oder
auch (noch) nicht. Glaubst Du mir jetzt, daß und warum ich nach einer
Möglichkeit suche, einem XCOPY-(Ersatz) Informationen aus der Nase
ziehen zu können, *welche* Datei(en) nicht verwurstet werden konnte(n)?

CU!
Ulrich

[Axel Berger]

Glaubst Du mir jetzt, daß und warum ich nach einer Möglichkeit
suche, einem XCOPY-(Ersatz) Informationen aus der Nase ziehen
zu können, *welche* Datei(en) nicht verwurstet werden konnte(n)?

Ich glaube Dir das von Anfang an und stimme genauso lange zu, daß eine
saubere Fehlermeldung es enthalten sollte. Aber wenn man wie so oft
nicht haben kann, was man will, dann hilft kein Jammern sondern nur die
Suche nach Alternativen. Kompromisse lassen sich selten dabei vermeiden.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Glaubst Du mir jetzt, daß und warum ich nach einer Möglichkeit
suche, einem XCOPY-(Ersatz) Informationen aus der Nase ziehen
zu können, *welche* Datei(en) nicht verwurstet werden konnte(n)?

Ich glaube Dir das von Anfang an und stimme genauso lange zu, daß eine
saubere Fehlermeldung es enthalten sollte. Aber wenn man wie so oft
nicht haben kann, was man will, dann hilft kein Jammern sondern nur die
Suche nach Alternativen.

Deswegen frage ich ja hier. Mir selbst fiel keine eine, außer im
jeweiligen konkreten Fall mehr oder minder zu Fuß die im konkreten
Fall jeweils betroffenen Quelle nch mögliche Kandidaten abzusuchen.
Und da hier ja die DOS-Koniferen wohnen ...

Post by Axel Berger
Kompromisse lassen sich selten dabei vermeiden.

Mangels aussagekräftiger Fehlermeldung nach /möglichen/ Ursachen suchen,
halte ich für keinen Kompromiss. So gut, wie eure Tipps auch immer jenes
erleichtern helfen: Wenn unten nicht irgendwie eine Liste der nicht
kopierten Dateien rausfällt, ist und bleibt es bestenfalls ein fauler.

Nix für Ungut und trotzdem freilich Dank für eure Mithilfe.

CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich
Wenn unten nicht irgendwie eine Liste der nicht
kopierten Dateien rausfällt, ist und bleibt es bestenfalls ein fauler.

Womit wir wieder beim Total Commander wären. Der ist in der Lage, zwei
Verzeichnisse samt Unterverzeichnissen zu vergleichen, und meldet Dir
auch brav alle Unterschiede.

Gruß
Claus

[Ulrich F. Heidenreich]

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich
Wenn unten nicht irgendwie eine Liste der nicht
kopierten Dateien rausfällt, ist und bleibt es bestenfalls ein fauler.

Womit wir wieder beim Total Commander wären. Der ist in der Lage, zwei
Verzeichnisse samt Unterverzeichnissen zu vergleichen,

Script- (oder eher batch-) gesteuert?

Post by Claus Reibenstein
und meldet Dir auch brav alle Unterschiede.

Wie meldet er mir das? In eine Datei umleitbar?

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Dir Q:\*.* /b /on /s > quelldir.txt
CD Qback
Dir *.* /b /on /s > zieldir.txt
fc quelldir.txt zieldir.txt

Anderer möglicher Weg, weil die Sortierung innerhalb des dir-Befehls
wegen zu vielen Dateien fehlschlägt:

Dir Q:\*.* /b /s |sort >quelldir.txt

oder

Dir Q:\*.* /b /s >tempfile.lst
sort tempfile.lst >quelldir.txt

Post by Ulrich F. Heidenreich
ein möglicher Ansatz? Oder scheitert fc an/ab der Stelle, an/ab der die
beiden Directorylistings wegen fehlendem Zielsdatei-Eintrag nicht mehr
"synchron" sind?

Wenn Du in den Listendateien vorher Q:\ bzw. Z:\QBack\ aus den
Dateinamen entfernst, sollte es funktionieren. Falls fc eine "Dateien
sind zu unterschiedlich"-Meldung bringt, kannst Du mit /LBx angeben, wie
viele unterschiedliche Zeilen erlaubt sind.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Dir Q:\*.* /b /on /s > quelldir.txt
CD Qback
Dir *.* /b /on /s > zieldir.txt
fc quelldir.txt zieldir.txt

Anderer möglicher Weg, weil die Sortierung innerhalb des dir-Befehls
Dir Q:\*.* /b /s |sort >quelldir.txt
oder
Dir Q:\*.* /b /s >tempfile.lst
sort tempfile.lst >quelldir.txt

<g> Intern macht die DOS-Pipe ja nichts Anderes. Kommt immer gut, wenn
man auf einem schreibgeschützen Laufwerk pipen will.

Post by Heiko Rost

Post by Ulrich F. Heidenreich
ein möglicher Ansatz? Oder scheitert fc an/ab der Stelle, an/ab der die
beiden Directorylistings wegen fehlendem Zielsdatei-Eintrag nicht mehr
"synchron" sind?

Wenn Du in den Listendateien vorher Q:\ bzw. Z:\QBack\ aus den
Dateinamen entfernst, sollte es funktionieren. Falls fc eine "Dateien
sind zu unterschiedlich"-Meldung bringt, kannst Du mit /LBx angeben, wie
viele unterschiedliche Zeilen erlaubt sind.

Auch wenn sie nicht mehr synchron sind? Wenn zum Beispiel

Quell-Liste = > Zielliste

A A
B B
C D
D E
E F
F

gilt, dürfte der Vergleich ab "C => D" immer schiefgehen, obwohl nur C
nicht "rüber" ging. Außerdem befürchte ich ein "unterschiedlich lang".

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Auch wenn sie nicht mehr synchron sind?

fc vergleicht zeilenweise, und sucht bei Unterschieden weiter hinten in
den Dateien, ob wieder identische Bereiche folgen. Und solange die
Unterschiede nicht zu groß sind, synchronisiert es sich wieder.

Post by Ulrich F. Heidenreich
Wenn zum Beispiel
Quell-Liste = > Zielliste
A A
B B
C D
D E
E F
F
gilt, dürfte der Vergleich ab "C => D" immer schiefgehen, obwohl nur C
nicht "rüber" ging.

In der Zeit, die Du hier auf die Antwort wartest, hättest Du schon ein
Testzenario mit diesen Zeilen bauen können:

| [D:\Temp_d]fc 1.txt 2.txt
| Vergleichen der Dateien 1.txt und 2.TXT
| ***** 1.txt
| b
| c
| d
| ***** 2.TXT
| b
| d
| *****

Post by Ulrich F. Heidenreich
Außerdem befürchte ich ein "unterschiedlich lang".

Falls Du meinst, daß die einzelnen Zeilen unterscheidlich lang sind:
Deshalb mein Hinweis, daß Du in den Quell- und Ziellisten vorher
unterschiedliche Laufwerks- und evtl. Pfadangaben wie z. B. Z:\QBack\
entfernen sollst.

Vollautomatisch per Batch geht das mit DOS-Bordmitteln wahrscheinlich
nicht (mit edlin wäre das vielleicht möglich, damit kenne ich mich nicht
aus). Das Stichwort 4DOS ist schon gefallen, ich fürchte allerdings, daß
das nur für diesen einen Einsatz zu viel an Einarbeitungszeit benötigt.
Falls das Programm jetzt wirklich Freeware ist (auf http://jpsoft.com/
finde ich nur tcc/le, und das ist ein Ersatz für cmd.exe), solltest Du
es Dir trotzdem näher anschauen. Das ist eine sehr umfangreiche
Erweiterung der Kommandozeile im Vergleich zu command.com.

Gruß Heiko

[Heiko Rost]

Post by Axel Berger

Post by Axel Berger
dir /b /on /s * > List.txt

Da fehlt ein /x in den Optionen, Du willst hier die kurzen Dateinamen.
Für die langen gilt iirc die 256-Byte-Grenze nicht.

Es müßten die langen Namen sein, zumindest unter XP und Windows 7(*) ist
es so. Mangels Windows 95 kann ich es dort nicht selber nachprüfen.

(*) Eine Datei d:\temp_d\LangerPfad\LangerName.txt ließ sich per
Explorer löschen (immerhin ein Fortschritt zu XP, da ging mit dem
Explorer gar nichts). Beim Versuch, sie mit "Bearbeiten" - "Löschen
rückgängig machen" wieder herzustellen, brachte den "Zielpfad zu
lang"-Dialog. Aus dem Papierkorb heraus funktionierte das
Wiederherstellen komischerweise. Unnötig zu erwähnen, daß das Öffnen der
Datei nicht mit jeder Textverarbeitung möglich war.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um
den Zielordnernamen ergänzt ein Längenlimit überschritten hat?

Mach ein
dir /b /on /s * > List.txt
in der Wurzel Deines Baumes. Dann siehst Du recht mühelos, welches die
längsten Zeilen sind.

Danke. Ist ne Möglichkeit. Doppeldanke, weil ich neulich auch mal nach
einer Möglichkeit suchte, eine Liste der kompletten Pfadnamen zu
bekommen und nicht nach Verzeichnissen aufgedröselt und darunter nur
noch die Dateinamen. Zwei Fliegen, eine Klappe.

CU!
Ulrich

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um
den Zielordnernamen ergänzt ein Längenlimit überschritten hat?

Mach ein
dir /b /on /s * > List.txt
in der Wurzel Deines Baumes. Dann siehst Du recht mühelos, welches die
längsten Zeilen sind.

BTDT.
Es scheitert aber an Meldungen der Form
|(Zu viele Dateien. Verzeichnis wird nicht sortiert.)

Zudem 5319 Einträge dahingehend abzuklappern, welcher nun mit
vorangestelltem "p4tb/..." zu lang wird, ist auch nicht gerade
unaufwändig. Schade. Trotzdem Danke.

CU!
Ulrich

[Herbert Kleebauer]

Post by Ulrich F. Heidenreich
|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da der
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

Ist schon so lange her, aber ich glaube, wenn du mit SUBST
einen Laufwerksbuchstaben für den Zielorder vergibst und
dann auf dieses Laufwerk kopierst, sollte es gehen. Über
den normalen Pfad kannst du dann aber auf die Datei nicht
zugreifen, weil der Pfad dann wieder zu lang ist, d.h.
auch zum lesen mußt du dann SUBST verwenden.

[Michael Bednarek]

On Tue, 21 Aug 2012 00:16:21 +0200, Herbert Kleebauer wrote in

Post by Herbert Kleebauer

Post by Ulrich F. Heidenreich
|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da der
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

Ist schon so lange her, aber ich glaube, wenn du mit SUBST
einen Laufwerksbuchstaben für den Zielorder vergibst und
dann auf dieses Laufwerk kopierst, sollte es gehen. Über
den normalen Pfad kannst du dann aber auf die Datei nicht
zugreifen, weil der Pfad dann wieder zu lang ist, d.h.
auch zum lesen mußt du dann SUBST verwenden.

Möglicherweise ist der Zugriff auf solche Dateien auch mit der Unicode
UNC Syntax möglich:
DIR \\?\C:\Pfad\mehrPfad\mehrPfad\ usw.

[Heiko Rost]

Post by Michael Bednarek
Möglicherweise ist der Zugriff auf solche Dateien auch mit der Unicode
DIR \\?\C:\Pfad\mehrPfad\mehrPfad\ usw.

Falls mich meine Erinnerung nicht täuscht, muß dafür bei Windows 95 der
Unicode-Layer installiert sein:

http://msdn.microsoft.com/en-US/goglobal/bb688166.aspx

Und auch dann funktioniert so lange Pfade nur bei sehr wenigen
Programmen.

Gruß Heiko

[Ulrich F. Heidenreich]

Den Artikel habe ich leider nicht.

Post by Michael Bednarek

Post by Herbert Kleebauer

Post by Ulrich F. Heidenreich
|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da der
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

Ist schon so lange her, aber ich glaube, wenn du mit SUBST
einen Laufwerksbuchstaben für den Zielorder vergibst und
dann auf dieses Laufwerk kopierst, sollte es gehen. Über
den normalen Pfad kannst du dann aber auf die Datei nicht
zugreifen, weil der Pfad dann wieder zu lang ist, d.h.
auch zum lesen mußt du dann SUBST verwenden.

Möglicherweise ist der Zugriff auf solche Dateien auch mit der Unicode
DIR \\?\C:\Pfad\mehrPfad\mehrPfad\ usw.

*Soifz*. Dazu müsste ich erstmal wissen, *wer* diese "solche Dateien"
sind. XCOPY meldet ja leider nur, *daß* der Zielpfad zu lang geworden
wäre, aber leider nicht, bei welcher Datei, welchen Dateien. Wenn der/
die Übeltöter einmal gefunden sind, wäre es ein Leichtes, ihn/sie in
ein anderes Verzeichnis näher an der Wurzel umzuziehen.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Und jetzt, wo mein Adrenalinspiegel inzwischen wieder auf verträgliche
Werte unten ist: Habe ich irgendeine Chance, die Übeltöterdatei anders
zu finden, als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um den
Zielordnernamen ergänzt ein Längenlimit überschritten hat?

Um die beiden anderen Antworten zu ergänzen:

Neben subst kann auch eine Netzwerkfreigabe des Zielordners benutzt
werden. Mit der selben Einschrängung, daß man dann mit den meisten
Programmen nur noch per subst oder Freigabe auf die Datei zugreifen
kann.

Der vollständige Dateiname darf maximal 260 Bytes lang sein, manchmal
findet man auch 250 oder 256. Wenn Du das selber recherchieren willst,
ist MAX_PATH ein guter Suchbegriff.

Gruß Heiko

[Ulrich F. Heidenreich]

Beiden?

Post by Heiko Rost
Neben subst kann auch eine Netzwerkfreigabe des Zielordners benutzt
werden.

Der Zielordner ist BTW eine Netzwerkfreigabe. Ich bin gerade dabei, ein
NAS zu füllen, weil mir eine 2-TByte-Blatte überzulaufen droht. Und bis
hinauf zu WinXP 32 Bit ist ab da Essig mit der Ansprechbarkeit.

Post by Heiko Rost
Mit der selben Einschrängung, daß man dann mit den meisten
Programmen nur noch per subst oder Freigabe auf die Datei zugreifen
kann.
Der vollständige Dateiname darf maximal 260 Bytes lang sein, manchmal
findet man auch 250 oder 256. Wenn Du das selber recherchieren willst,
ist MAX_PATH ein guter Suchbegriff.

Inwieweit hilft mir das, den Übeltäter zu finden? Denn der bleibt ja auf
der 2 TByte liegen und wandert nicht ins NAS rüber.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Inwieweit hilft mir das, den Übeltäter zu finden? Denn der bleibt ja auf
der 2 TByte liegen und wandert nicht ins NAS rüber.

Die Syntax für den dir-Befehl hast Du in <***@Gmx.De>
bekommen. Damit läßt Du den Inhalt des Quellverzeichnisses auflisten. In
der Liste findest Du dann relativ einfach die längsten Namen, und das
sind dann die Dateien, die mit hoher Wahrscheinlichkeit nicht kopiert
wurden.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Inwieweit hilft mir das, den Übeltäter zu finden? Denn der bleibt ja auf
der 2 TByte liegen und wandert nicht ins NAS rüber.

bekommen. Damit läßt Du den Inhalt des Quellverzeichnisses auflisten. In
der Liste findest Du dann relativ einfach die längsten Namen, und das
sind dann die Dateien, die mit hoher Wahrscheinlichkeit nicht kopiert
wurden.

Neben der Tatsache, daß das leider nicht so ganz funktionierte, möchte
ich eigentlich nicht selbst herausfinden müssen, welche das "mit hoher
Wahrscheinlichkeit sein könnten", sondern sicher gemeldet bekommen,
welche tatsächlich nicht kopiert wurden. Also nicht "einige Daten
konnten nicht kopiert werden", sondern "Datei \foo\bar, \bar\foo,
\foobar\barfoo, barfoo\foobar\... konnten nicht kopiert werden".

Ein dazu eigentlich geeignetes ("Q:" sei wieder die Quelle, "Z:\Qback"
das Ziel) ...

Q:
for %x in (*.*) do if not exist Z:\Qback\%x echo %x >> missing.txt

... scheitert leider daran, daß die for-Syntax kein "/s" kennt. Und
das für jedes Unterverzeichnis einzeln zu machen, wäre auch wieder
Syphillis-Arbeit, denn "Q:" besitzt 155 Unterverzeichnisse.

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
... scheitert leider daran, daß die for-Syntax kein "/s" kennt.

4DOS ist seit längerer Zeit Freeware, es gibt IMHO keinen vernünftigen
Grund, es nicht zu verwenden.

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
... scheitert leider daran, daß die for-Syntax kein "/s" kennt.

4DOS ist seit längerer Zeit Freeware, es gibt IMHO keinen vernünftigen
Grund, es nicht zu verwenden.

Was der Bauer nicht kennt, ...

CU!
Ulrich

[Michael Bednarek]

On Tue, 21 Aug 2012 12:45:51 +0200, Axel Berger wrote in

Post by Axel Berger

Post by Ulrich F. Heidenreich
... scheitert leider daran, daß die for-Syntax kein "/s" kennt.

4DOS ist seit längerer Zeit Freeware, es gibt IMHO keinen vernünftigen
Grund, es nicht zu verwenden.

Guter Vorschlag. Folgendes 4DOS Batchprogramm listed Dateinamen die
länger sind als vorherige; der/die Übeltäter sollten unter den letzten
gelisteten sein. Das dauert natürlich etwas; hier waren es 12 1/2
minuten. Ich vermute, Win95-Batch Gurus können etwas ähnliches auch mit
Bordmitteln erstellen.

@ECHO OFF
*SETLOCAL
UNALIAS *

SET Mxtl=0

SET nFiles=0
TIMER ON
FOR /R . %fn IN (*.*) GOSUB Process
TIMER OFF
ECHO %nFiles Dateien inspiziert.
QUIT

:Process
SET /A nFiles=%nFiles + 1
SET tl=%@LEN[%fn]
IFF %tl GT %Mxtl THEN
SET Mxtl=%tl
ECHO Pfad: %@FORMAT[03,%tl] %fn
ENDIFF
RETURN

[Axel Berger]

Post by Ulrich F. Heidenreich
Inwieweit hilft mir das, den Übeltäter zu finden?

Eine weitere Möglichkeit wäre, (nach einem Backup) nicht copy sondern
move. Dann siehst Du gleich, was übrigbleibt.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Inwieweit hilft mir das, den Übeltäter zu finden?

Eine weitere Möglichkeit wäre, (nach einem Backup)

Das Ziel ist das Backup. #-)

Post by Axel Berger
nicht copy sondern
move. Dann siehst Du gleich, was übrigbleibt.

Netter Ansatz; ist mir aber zu gefährlich.

CU!
Ulrich

[Herbert Kleebauer]

Post by Ulrich F. Heidenreich
Das Ziel ist das Backup. #-)

Das Backup kannst du ja mittels SUBST machen und wenn
sich dann später ein Programm beschwert, daß der Pfad
zulange ist, kannst du die entsprechenden Dateien immer
noch (wieder mittels SUBST) woanders hin kopieren.

Vielleicht hift es aber auch schon, dem Backup-Order
einen ganz kurzen Namen zu geben, damit die Pfade
nur minimal länger werde.

Oder vergleiche die Ausgabe von xcopy /L mit der Ausgabe
des echten Kopiervorgangs.

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Inwieweit hilft mir das, den Übeltäter zu finden?

Eine weitere Möglichkeit wäre, (nach einem Backup) nicht copy sondern
move. Dann siehst Du gleich, was übrigbleibt.

Ich bin's nochmal: Kennt "move" denn ein "/s"?

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
Ich bin's nochmal: Kennt "move" denn ein "/s"?

Ehrlich gesagt nehme ich für so etwas nicht DOS sondern den
Totalcommander. Der kann's auf jeden Fall, es gibt ihn auch immer noch
gepflegt für 16-bit Systeme, er kostet sehr wenig, und die Demoversion
ist bis auf einen minimalen Nag vollkommen uneingeschränkt.

Das MOVE von 4DOS kann es aber auch.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Ich bin's nochmal: Kennt "move" denn ein "/s"?

Ehrlich gesagt nehme ich für so etwas nicht DOS sondern den
Totalcommander.

Kann man den scripten?

Post by Axel Berger
Das MOVE von 4DOS kann es aber auch.

Bringt mich aber auch nicht sonderlich weiter, weil ich das Risiko nicht
eingehen möchte. Gebranntes Kind scheut das Feuer: Ich habe mal per
Bunktklick (Damit geht ja ein Verschieben ganzer Verzeichnisstrukturen)
Daten ins Nirwana verschoben. Ab da wird grundsätzlich nur kopiert und
nach Kontrolle der Kopie die Quelle gelöscht.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Und die würde mir ziemlich leichter fallen, könnte man trivial heraus-
bekommen, *was* - aus welchen Gründen auch immer, es muss noch nicht
einmal "Pfad zu lang" sein - nicht kopiert wurde. *Daß* irgendwas nicht
kopiert wurde, ist dabei wenig hilfreich.

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Post by Ulrich F. Heidenreich
Ab da wird grundsätzlich nur kopiert und
nach Kontrolle der Kopie die Quelle gelöscht.

Das wiederum macht er hervorragend: Zwei Bäume vergleichen, Unterschiede
zeigen und auf Wunsch gleich machen. Was er kann, und das ist eine
Menge, macht er wirklich hervorragend.

Axel

[Ulrich F. Heidenreich]

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Damit fällt der aus. Buntrumklicken will ich nicht.

CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Damit fällt der aus. Buntrumklicken will ich nicht.

Brauchst Du auch nicht. Der Total Commander lässt sich komplett per
Tastatur bedienen.

Was genau möchtest Du eigentlich "scripten"?

Gruß
Claus

[Ulrich F. Heidenreich]

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Damit fällt der aus. Buntrumklicken will ich nicht.

Brauchst Du auch nicht. Der Total Commander lässt sich komplett per
Tastatur bedienen.

An der sitzt aber niemand, während nachts das "Backup" läuft.

Post by Claus Reibenstein
Was genau möchtest Du eigentlich "scripten"?

Ne ganze Menge, konkret ist diese Passage betroffen:

|net use Q: \\qnap1\p4tb /Y
|xcopy G:\*.* Q:\driveG /s /d /c /y > C:\xcgqnap.log
|xcopy E:\QuellSave\*.* Q:\QuellSave /s /d /c /y
|xcopy Y:\bootsave\*.* Q:\win95gho /s /d /c /y
|xcopy Y:\batchbak\*.* Q:\batches /s /d /c /y
|attrib H:\hamster +h
|xcopy H:\*.* Q:\driveH /s /d /c /y
|attrib H:\hamster -h
|net use Q: /delete /Y
|net use Q: \\qnap1\cambilder /Y
|xcopy G:\cambilder\*.* Q: /s /d /c /y
|net use Q: /delete /Y

Und aus der meldet die Zeile

|xcopy G:\*.* Q:\driveG /s /d /c /y > C:\xcgqnap.log

|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da de
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

Wobei ich allerdings inzwischen schon fast auf eine (Win-)DO(w)S-
typische falsche Fehlermeldung tippe. Zum Debuggen habe ich nun dieses

|> C:\xcgqnap.log

mit hereingenommen, da steht aber aktuell nur

|G:\TEMP\$temp$
|G:\TEMP\AMANAMAC
|G:\TEMP\AMANAMAH
|G:\Dokumente\private Daten\haushalt.xls
|G:\Dokumente\private Daten\haushalt-neu.xls
|G:\Dokumente\Konto\konten.xls
|G:\Dokumente\Konto\123gold.tmp
|G:\Dokumente\Desktop\FINANZEN\AUSGABEN.LNK
|G:\Dokumente\Desktop\FINANZEN\maple.lnk
|G:\Dokumente\csv\082212.pdf
|G:\Mail&News Downloads\Pic4.jpg
|G:\Mail&News Downloads\Pic5.jpg
|G:\Mail&News Downloads\md50000113999.txt
|G:\Temporary Internet Files\Content.IE5\index.dat
|G:\Quellen\ct-Utilities\SAR.EXE
|G:\n\n082212.jpg
|G:\n\d082212.jpg
| 17 Datei(en) kopiert

drin. Oder DOS ist zudem noch so schlau,XCOPY die Zeilem, bei denen es
einen zu langen Zielpfad erzeugen würde, auch dort nicht ausgeben zu
lassen.


CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Damit fällt der aus. Buntrumklicken will ich nicht.

Brauchst Du auch nicht. Der Total Commander lässt sich komplett per
Tastatur bedienen.

An der sitzt aber niemand, während nachts das "Backup" läuft.

Irgendwie reden wir aneinander vorbei.

Du hast ein Backup-Script, welches Dir meldet, dass irgendetwas nicht
kopiert wurde, und möchtest nun wissen, was genau nicht kopiert wurde.
Richtig?

Dies kannst Du mit Total Commander feststellen. Dies passiert aber nicht
nachts während des Backups, sondern danach, wenn Du die Fehlermeldung
gesehen hast und Dich nun _manuell_ auf die Suche machen möchtest.

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Was genau möchtest Du eigentlich "scripten"?

|net use Q: \\qnap1\p4tb /Y
|xcopy G:\*.* Q:\driveG /s /d /c /y > C:\xcgqnap.log
|xcopy E:\QuellSave\*.* Q:\QuellSave /s /d /c /y
|xcopy Y:\bootsave\*.* Q:\win95gho /s /d /c /y
|xcopy Y:\batchbak\*.* Q:\batches /s /d /c /y
|attrib H:\hamster +h
|xcopy H:\*.* Q:\driveH /s /d /c /y
|attrib H:\hamster -h
|net use Q: /delete /Y
|net use Q: \\qnap1\cambilder /Y
|xcopy G:\cambilder\*.* Q: /s /d /c /y
|net use Q: /delete /Y

Ist das Dein "Backup"? Ich würde vorschlagen, statt diesem Hack eine
vernünftige Backup-Software einzusetzen.

Post by Ulrich F. Heidenreich
Und aus der meldet die Zeile
|xcopy G:\*.* Q:\driveG /s /d /c /y > C:\xcgqnap.log
|Warnung: Nicht alle Dateien wurden gefunden/kopiert, da de
|entstehende Pfad- bzw. Dateiname zu lang geworden wäre.

Und genau hier kommt Total Commander zum Zuge: Du öffnest im linken
Fenster G:\ und im rechten Q:\driveG\ und lässt ihn rödeln.

Natürlich kannst Du auch gleich Total Commander zum Kopieren benutzen.
Dann siehst Du sofort, wo es klemmt. Allerdings musst Du dann die
Kopieroperation manuell anwerfen.

Gruß
Claus

[Axel Berger]

Post by Claus Reibenstein
Natürlich kannst Du auch gleich Total Commander zum Kopieren benutzen.

In dem Fall eher nicht. Bei einer langen Liste verschiedener Quell- und
Zielverzeichnisse wie hier wird das irgendwann lästig und auch ich würde
eine automatisiertbare Lösung suchen. Gezielt auf das Problemverzeichnis
angesetzt natürlich schon.

Post by Claus Reibenstein
danach, wenn Du die Fehlermeldung gesehen hast und Dich
nun _manuell_ auf die Suche machen möchtest.

Eben. Für manuelle one-offs ist er unschlagbar.

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Claus Reibenstein
Natürlich kannst Du auch gleich Total Commander zum Kopieren benutzen.

In dem Fall eher nicht. Bei einer langen Liste verschiedener Quell- und
Zielverzeichnisse wie hier wird das irgendwann lästig und auch ich würde
eine automatisiertbare Lösung suchen. Gezielt auf das Problemverzeichnis
angesetzt natürlich schon.

Welches denn? #-)

CU!
Ulrich

[Ulrich F. Heidenreich]

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Ulrich F. Heidenreich
Kann man den scripten?

Nein.

Damit fällt der aus. Buntrumklicken will ich nicht.

Brauchst Du auch nicht. Der Total Commander lässt sich komplett per
Tastatur bedienen.

An der sitzt aber niemand, während nachts das "Backup" läuft.

Irgendwie reden wir aneinander vorbei.
Du hast ein Backup-Script, welches Dir meldet, dass irgendetwas nicht
kopiert wurde, und möchtest nun wissen, was genau nicht kopiert wurde.
Richtig?

Richtig. Immer! Jenes Script sollte mir das melden.

Post by Claus Reibenstein
Dies kannst Du mit Total Commander feststellen.

Wie binde ich den in das Script ein?

Post by Claus Reibenstein
Dies passiert aber nicht
nachts während des Backups, sondern danach, wenn Du die Fehlermeldung
gesehen hast und Dich nun _manuell_ auf die Suche machen möchtest.

Genau das möchte ich ja eben nicht müssen.

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
Genau das möchte ich ja eben nicht müssen.

Das kann ich zwar verstehen, aber solange solche unkopierbaren Pfade die
seltene Ausnahme bleiben, lohnt der Aufwand nicht und die manuelle
Lösuhg reicht vollkommen aus. Nacharbeiten mußt Du ohnehin manuell und
wenn es öfter vorkommt, ist etwas grundsätzlich verkehrt.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Genau das möchte ich ja eben nicht müssen.

Das kann ich zwar verstehen, aber solange solche unkopierbaren Pfade die
seltene Ausnahme bleiben,

Ich merke sie ja normalerweise gar nicht, weil ich der Batchdatei
seltenst bei der Arbeit über die Schulter schaue. Und XCopy setzt
AFAIK (ich kann aber auch irren und werde das nochmal checken) in
dem Fall auch keinen Errorlevel.

Post by Axel Berger
lohnt der Aufwand nicht und die manuelle
Lösuhg reicht vollkommen aus.

Die manuelle Lösung wäre im Gegenteil der Aufwand.

Post by Axel Berger
Nacharbeiten mußt Du ohnehin manuell

Wenn der Batch wüßte, *welche* Dateien nicht kopiert wurden, dann
könnte er sie statt nach "Z:\Qback\$Langer_Quellpfad" zum Beispiel
nach "Z:\Lost&Found\$Dateiname" kopieren. (Nur) wenn da plötzlich
was drinstünde, wäre ein manueller Eingriff notwendig.

Post by Axel Berger
und wenn es öfter vorkommt, ist etwas grundsätzlich verkehrt.

Nicht unbedingt. Es könnten zum Beispiel komplette FTP-Spiegel sein,
die entsprechend lange Dateinamen übernahmen. Da gibt's dann sowas wie

G:\Dokumente\TechnischeDoku\asus\Treiber&Bios\treiber\LAN\Intel\100pboot.exe

Und das ist noch nichteinmal der längste.

CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Axel Berger

Post by Ulrich F. Heidenreich
Genau das möchte ich ja eben nicht müssen.

Das kann ich zwar verstehen, aber solange solche unkopierbaren Pfade die
seltene Ausnahme bleiben,

Ich merke sie ja normalerweise gar nicht, weil ich der Batchdatei
seltenst bei der Arbeit über die Schulter schaue.

Du lässt kein Protokoll mitlaufen, welches Du kontrollieren kannst? Nun,
in diesem Fall _musst_ Du manuell kontrollieren. Womit wir abermals bei
Total Commander angekommen wären.

Post by Ulrich F. Heidenreich
Wenn der Batch wüßte, *welche* Dateien nicht kopiert wurden, dann
könnte er sie statt nach "Z:\Qback\$Langer_Quellpfad" zum Beispiel
nach "Z:\Lost&Found\$Dateiname" kopieren.

Ich glaube nicht, dass es irgendwo ein fertiges Produkt gibt, welches so
etwas leisten kann. Das wirst Du Dir selber programmieren müssen.

Die IMHO einzige vernünftige Alternative wäre der Einsatz einer
richtigen Backup-Software.

Gruß
Claus

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Du hast ein Backup-Script, welches Dir meldet, dass irgendetwas nicht
kopiert wurde, und möchtest nun wissen, was genau nicht kopiert wurde.
Richtig?

Richtig. Immer! Jenes Script sollte mir das melden.

Das Script meldet es aber nicht. XCOPY meldet es nicht. Ergo: XCOPY ist
das falsche Werkzeug.

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Dies kannst Du mit Total Commander feststellen.

Wie binde ich den in das Script ein?

GAR NICHT!

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Dies passiert aber nicht
nachts während des Backups, sondern danach, wenn Du die Fehlermeldung
gesehen hast und Dich nun _manuell_ auf die Suche machen möchtest.

Genau das möchte ich ja eben nicht müssen.

Dann musst Du XCOPY durch etwas Anderes ersetzen. Dazu habe ich an
anderer Stelle schon was Passendes geschrieben.

Gruß
Claus

[Ulrich F. Heidenreich]

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Du hast ein Backup-Script, welches Dir meldet, dass irgendetwas nicht
kopiert wurde, und möchtest nun wissen, was genau nicht kopiert wurde.
Richtig?

Richtig. Immer! Jenes Script sollte mir das melden.

Das Script meldet es aber nicht. XCOPY meldet es nicht. Ergo: XCOPY ist
das falsche Werkzeug.

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Dies kannst Du mit Total Commander feststellen.

Wie binde ich den in das Script ein?

GAR NICHT!

Wieso ist er dann laut <news:***@mid.individual.net> die
Lösung? Langsam kommst Du mir wie der mit Verlaub - Linux-Idiot vor, der
auf jede Frage nach einer Windows-Lösung mit "Nimm Linux" antwortet.

CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Du hast ein Backup-Script, welches Dir meldet, dass irgendetwas nicht
kopiert wurde, und möchtest nun wissen, was genau nicht kopiert wurde.
Richtig?

Richtig. Immer! Jenes Script sollte mir das melden.

Das Script meldet es aber nicht. XCOPY meldet es nicht. Ergo: XCOPY ist
das falsche Werkzeug.

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Dies kannst Du mit Total Commander feststellen.

Wie binde ich den in das Script ein?

GAR NICHT!

Lösung?

Er ist die Lösung, um _nachträglich_ festzustellen, was nicht kopiert
wurde. Er ist _nicht_ die Lösung, um Dein Script zu ersetzen.
Insbesondere ist er _keine_ Backup-Lösung.

Post by Ulrich F. Heidenreich
Langsam kommst Du mir wie der mit Verlaub - Linux-Idiot vor, der
auf jede Frage nach einer Windows-Lösung mit "Nimm Linux" antwortet.

Vielleicht versuchst Du einfach mal, das, was ich schrieb, so zu
verstehen, wie es da steht, anstatt es in Deinem Sinne umzuinterpretieren.

Sagte ich schon, dass ich den Eindruck hätte, wir redeten aneinander vorbei?

Gruß
Claus

[Ulrich F. Heidenreich]

Post by Claus Reibenstein
Er ist die Lösung, um _nachträglich_ festzustellen, was nicht kopiert
wurde.

Dafür suchte ich aber keine, sondern eine, um die nachträgliche Suche
von vorneherein zu vermeiden.

Die zudem nach aktuellem Stand der Dinge eh hyperfluid geworden wäre,
egal wie elegant oder grob man sie durchführt. Derweil bin ich mir
nämlich ziemlich sicher, Opfer einer falschen Fehlermeldung geworden zu
sein: Auf der Quellplatte befindet sich auch die Win386.swp. Die meldet
XCOPY korrekt mit Namen als nicht kopierbar. Dies scheint nun irgendein
Fehlerflag zu setzen, welches nach Abschluss des gesamten Kopiervorgangs
falsch interpretiert wird.

Und was Deinen ebenfalls am Thema vorbeigehenden Vorschlag, ein "echtes"
Backupprogramm zu nehmen, anbetrifft: Dessen Backup müsste ich Falle des
Rechnertodes wieder irgendwohin zurückspielen. Die XCOPY-Redundanz sorgt
jedoch dafür, sofort mit einem anderen Rechner auf die Datenbestände
zugreifen zu können. Sie lagern einmal auf dem Hauptrechner, einmal auf
einem Ersatzrechner und neuerdings noch einmal auf einem NAS. Zudem
gehören zu den "Daten" auch Filme und MP3s, die auch erstmal vom
"Aufnahmegerät"¹) aufs NAS wollen. Immer wieder ein Backup restaurieren,
wenn ich im anderen Zimmer hören oder sehen möchte, käme irgendwie nicht
so ganz prickelnd.

Aber das eher am Rande ...

CU!
Ulrich
________________
¹) Für CDs ist es der olle DOS/Win95-Rechner, in dem steckt noch ein
dafür unschlagbares SCSI-Plextor. Als Videorecorder läuft ein Netbook
mit XP.

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Er ist die Lösung, um _nachträglich_ festzustellen, was nicht kopiert
wurde.

Dafür suchte ich aber keine

Dann muss ich "Habe ich irgendeine Chance, die Übeltöterdatei anders
zu finden, als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um den
Zielordnernamen ergänzt ein Längenlimit überschritten hat?" aus
<k0tqij.3vse9df.1!not-for-***@ufh.invalid.de>, dem Ursprungsposting
dieses Threads, wohl irgendwie falsch verstanden haben ...

Post by Ulrich F. Heidenreich
Und was Deinen ebenfalls am Thema vorbeigehenden Vorschlag, ein "echtes"

Wieso "am Thema vorbeigehend"? Du hast doch selber den Begriff "Backup"

Post by Ulrich F. Heidenreich
Dessen Backup müsste ich Falle des
Rechnertodes wieder irgendwohin zurückspielen.

Das ist der Sinn eines Backups.

Post by Ulrich F. Heidenreich
Immer wieder ein Backup restaurieren,
wenn ich im anderen Zimmer hören oder sehen möchte, käme irgendwie nicht
so ganz prickelnd.

Von einer solchen Nutzung war, so weit ich sehe, nirgends die Rede.

Gruß
Claus

[Ulrich F. Heidenreich]

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich

Post by Claus Reibenstein
Er ist die Lösung, um _nachträglich_ festzustellen, was nicht kopiert
wurde.

Dafür suchte ich aber keine

Dann muss ich "Habe ich irgendeine Chance, die Übeltöterdatei anders
zu finden, als mich zu Fuß durch Myriaden von Quelldatien zu wuselen
und sie ebenfalls zu Fuß dahingehend abzuchecken, ob ihr Name um den
Zielordnernamen ergänzt ein Längenlimit überschritten hat?"

Anders. Durch irgendeinen Mechanismus, der beim Kopierversuch Alarm
gibt. Die XCOPY-Meldung hat dagegen den Charme eines "Ich sehe was,
was Du nicht siehst".

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich
Dessen Backup müsste ich Falle des
Rechnertodes wieder irgendwohin zurückspielen.

Das ist der Sinn eines Backups.

Aber nicht Sinn der XCOPY-Übung. Das soll Daten bereithalten.
Sicherheitshalber redundant. Durch diese Redundanz erübrigt sich
ein Backup mit dem Nachteil, erstmal irgendwohin ein Restore fahren
zu müssen, bevor die Daten wieder im Zugriff sind. Aber ich glaube,
da erzähle ich Dir nichts Neues.

Post by Claus Reibenstein

Post by Ulrich F. Heidenreich
Immer wieder ein Backup restaurieren,
wenn ich im anderen Zimmer hören oder sehen möchte, käme irgendwie nicht
so ganz prickelnd.

Von einer solchen Nutzung war, so weit ich sehe, nirgends die Rede.

Mit einem Backup-Programm ginge es aber nicht anders.

Darf ich diesen inzwischen konstruktivitätslosen Smalltalk dahingehend
resümmieren, daß auch Du keine mehr oder weniger triviale Möglichkeit
siehst, einem XCOPY (-Ersatz) verwertbare Fehlermeldungen aus der Nase
zu ziehen? Falls ja: Nuhr.

CU!
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
Dafür suchte ich aber keine, sondern eine, um die nachträgliche Suche
von vorneherein zu vermeiden.

Einerseits verständlich, aber:
Eine Fehlermeldung hast Du.
Die Fehlerbehebung muß ohnehin manuell erfolgen.
Wo ist das große Problem, das dieses Aufwandes wert wäre?

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Dafür suchte ich aber keine, sondern eine, um die nachträgliche Suche
von vorneherein zu vermeiden.

Eine Fehlermeldung hast Du.

Eine vom "Irgendwo ist irgendwas schiefgelaufen, aber wo und was
verrate ich Dir dummen User nicht"-Charme. Passt voll in die "Befehl
oder Dateinamen nicht gefunden"-Kiste des DOS. Soll Dumpfuser doch
selbst herausfinden, *welcher* Befehl oder Dateiname nicht gefunden
wurde. Es ihm zu verraten, wäre ja langweilig ...

Post by Axel Berger
Die Fehlerbehebung muß ohnehin manuell erfolgen.

Welcher Fehler? Jedesmal? Bei jedem XCOPY? Liegt überhaupt der gemeldete
Fehler vor?

Post by Axel Berger
Wo ist das große Problem, das dieses Aufwandes wert wäre?

Hä? Es ist doch *gerade* immenser Aufwand, der mir von euch als "Lösung"
empfohlen wurde. Jenen zu vermeiden, gilt es doch!

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Hä? Es ist doch *gerade* immenser Aufwand, der mir von euch als "Lösung"
empfohlen wurde. Jenen zu vermeiden, gilt es doch!

Dann arbeite Dich in 4DOS oder eine andere, umfangreichere Skriptsprache
als Standard-DOS ein. Damit kannst Du in Deinem Skript ein
Kopier-Unterprogramm erstellen, das nach dem Kopieren Quell- und
Zielpfad vergleicht. Du hast genau einmal den Aufwand, das zu schreiben
und zu testen, kannst es aber in Zukunft immer wieder benutzen und
sicher sein, daß das Kopieren korrekt ablief.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Hä? Es ist doch *gerade* immenser Aufwand, der mir von euch als "Lösung"
empfohlen wurde. Jenen zu vermeiden, gilt es doch!

Dann arbeite Dich in 4DOS oder eine andere, umfangreichere Skriptsprache
als Standard-DOS ein.

4DOS ersetzt AFAIK den Kommandointerpreter. Ist 4DOS voll COMMAND.COM
abwärtskompatibel? Falls nicht, könnte ich das knicken. Hier läuft sehr
viel über *.BAT.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
4DOS ersetzt AFAIK den Kommandointerpreter.

Es ist ein alternativer Kommandointerpreter, Du kannst ihn parallel zu
command.com installieren und benutzen.

Post by Ulrich F. Heidenreich
Ist 4DOS voll COMMAND.COM abwärtskompatibel?

Da bin ich mir nicht absolut sicher, es ist zu lange her, daß ich zu
4DOS gewechselt hatte.

Post by Ulrich F. Heidenreich
Falls nicht, könnte ich das knicken. Hier läuft sehr
viel über *.BAT.

Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen. Dadurch bemerken Deine
alten Batchdateien gar nicht, daß 4DOS installiert ist. Und für neue,
die unter 4DOS laufen müssen, kannst Du die Erweiterung .btm benutzen.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
4DOS ersetzt AFAIK den Kommandointerpreter.

Es ist ein alternativer Kommandointerpreter, Du kannst ihn parallel zu
command.com installieren und benutzen.

Post by Ulrich F. Heidenreich
Ist 4DOS voll COMMAND.COM abwärtskompatibel?

Da bin ich mir nicht absolut sicher, es ist zu lange her, daß ich zu
4DOS gewechselt hatte.

Post by Ulrich F. Heidenreich
Falls nicht, könnte ich das knicken. Hier läuft sehr
viel über *.BAT.

Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen.

Damit läuft aber dann der 4DOS nicht, nicht wahr?

Post by Heiko Rost
Dadurch bemerken Deine
alten Batchdateien gar nicht, daß 4DOS installiert ist. Und für neue,
die unter 4DOS laufen müssen, kannst Du die Erweiterung .btm benutzen.

Im Moment verstehe ich da nur Bahnhof und Kofferklauen.

CU!
Ulrich

[Claus Reibenstein]

Post by Ulrich F. Heidenreich

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Falls nicht, könnte ich das knicken. Hier läuft sehr
viel über *.BAT.

Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen.

Damit läuft aber dann der 4DOS nicht, nicht wahr?

Post by Heiko Rost
Dadurch bemerken Deine
alten Batchdateien gar nicht, daß 4DOS installiert ist. Und für neue,
die unter 4DOS laufen müssen, kannst Du die Erweiterung .btm benutzen.

Im Moment verstehe ich da nur Bahnhof und Kofferklauen.

Sorry, aber wenn Du nicht mal das verstehst, dann kann Dir vermutlich
keiner helfen. Für mich hast Du Dich jedenfalls soeben endgültig
disqualifiziert.

EOD

Claus

[Ulrich F. Heidenreich]

EOD

Danke. Von Dir kam eh nichts Konstruktives.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen.

Damit läuft aber dann der 4DOS nicht, nicht wahr?

Irgendwie verstehe ich jetzt Bahnhof. Du kannst aus der
MS-DOS-Kommandozeile heraus einfach 4dos.com aufrufen. Dann hast Du die
4DOS-Kommandozeile mit allen ihren Möglichkeiten, obwohl das System mit
command.com gestartet wurde. Anders herum geht es auch: Du stellst
komplett auf 4DOS um, und wenn irgendeine vorhandene Batch-Datei damit
nicht läuft, rufst Du diese mit

command.com /c batch.bat

auf. Aus Windows heraus ist es egal, ob Du für ein DOS-Fenster
command.com oder 4dos.com startest. So kannst Du je nach Bedarf mit
einem von beidem arbeiten.

Als mögliches Problem bei so einem Mischmasch sehe ich nur, daß comspec
möglicherweise auf den falschen Kommandoprozessor verweist und
Programme, die das auswerten, ggf. den falschen aufrufen.

Um einen Eindruck von den Möglichkeiten zu bekommen, kannst Du Dir die
FAQ unter <http://www.4dos.info/4batfaq.htm> durchlesen. Eine testweise
Installation von 4DOS ist auch unproblematisch (war zumindest in der
Version 3 oder 4 so, die ich unter Windows 98 hatte). Sichere Dir vorher
die config.sys und autoexec.bat, und wenn Du wieder MS-DOS haben willst,
benutzt Du diese gesicherten Dateien und änderst unter Windows die
Verknüpfungen von .bat auf command.com zurück.

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Dadurch bemerken Deine
alten Batchdateien gar nicht, daß 4DOS installiert ist. Und für neue,
die unter 4DOS laufen müssen, kannst Du die Erweiterung .btm benutzen.

Im Moment verstehe ich da nur Bahnhof und Kofferklauen.

Es gibt unter 4DOS für Batch-Dateien zusätzlich noch die Erweiterung
.btm (Batch To Memory). Diese werden komplett in den Speicher geladen
und nicht wie .bat-Dateien erst während der Ausführung zeilenweise
eingelesen.

Damit kannst Du unter Windows .bat immer noch mit command.com verknüpft
lassen, so daß mit einem Doppelklick darauf automatisch MS-DOS benutzt
wird.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen.

Damit läuft aber dann der 4DOS nicht, nicht wahr?

Irgendwie verstehe ich jetzt Bahnhof.

Wenn's der gleiche ist, wär'S vielleicht gar nicht so schlimm #-)

Post by Heiko Rost
Du kannst aus der
MS-DOS-Kommandozeile heraus einfach 4dos.com aufrufen. Dann hast Du die
4DOS-Kommandozeile mit allen ihren Möglichkeiten, obwohl das System mit
command.com gestartet wurde.

Es sollen aber doch Batchdateien ohne Interaktivität laufen. Batches, in
denen ich laut - u.a. - Deiner Empfehlung was Besseres als das XCOPY des
COMMAND.COM nutzen könnte.

Post by Heiko Rost
Anders herum geht es auch: Du stellst
komplett auf 4DOS um,

Deswegen meine Frage nach der Abwärtskompatibilität.

Post by Heiko Rost
Als mögliches Problem bei so einem Mischmasch sehe ich nur, daß comspec
möglicherweise auf den falschen Kommandoprozessor verweist und
Programme, die das auswerten, ggf. den falschen aufrufen.

Dss sehe ich so ziemlich gegeben. Ähnliches Späßchen hatte ich bei der
Portierung einiger Batches von Win95 nach XP: "Getenv ('Temp')" aus
einem TP-Kompilat heraus ergab da was anderes als %temp%. ABer das ist
ne andere Baustelle.

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Im Moment verstehe ich da nur Bahnhof und Kofferklauen.

Es gibt unter 4DOS für Batch-Dateien zusätzlich noch die Erweiterung
.btm (Batch To Memory). Diese werden komplett in den Speicher geladen
und nicht wie .bat-Dateien erst während der Ausführung zeilenweise
eingelesen.
Damit kannst Du unter Windows .bat immer noch mit command.com verknüpft
lassen,

Und wie nutze ich dann in einer solchen *.bat einen 4DOS-Befehl statt
eines COMMAND.COM-Befehls?

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Es sollen aber doch Batchdateien ohne Interaktivität laufen. Batches, in
denen ich laut - u.a. - Deiner Empfehlung was Besseres als das XCOPY des
COMMAND.COM nutzen könnte.

XCOPY ist ein externen Befehl, bei dem ist es egal, ob er von 4DOS oder
MS-DOS aus aufgerufen wird. Meine Empfehlung für 4DOS war hauptsächlich
wegen den besseren Möglichkeiten, den Erfolg oder Mißerfolg des
Kopierens zu testen. Auf die Schnelle fallen mir zwei Wege dafür ein:

1) Du kannst rekursiv die Unterverzeichnisse der Quelle durchlaufen und
kontrollieren, ob jeder Datei in diesem Verzeichnis auch im Ziel
vorhaden ist. Zusätzlich kannst Du auch noch Dateigröße und
Änderungsdatum vergleichen.

2) Du kannst die Textdateien aus dem angedachten "dir ... >liste.lst"
zeilenweise abarbeiten, ggf. führende Laufwerks-/Pfadangaben
entfernen und diese dann fc zum Vergleichen geben oder gleich auf das
Vorhandensein jeder Datei aus der Liste im Zielverzeichnis testen.

Vielleicht kannst Du auch auf das xcopy verzichten und copy benutzen
(das ist ein interner Befehl und der kann mehr als die MS-DOS-Version),
auf die Schnelle fallen mir die Optionen /s(ub), /u(pdate) und /v(erify)
ein.

Ob der nachträgliche Test oder copy besser ist, mußt Du selber
ausprobieren. Irgendeine Mehrarbeit hast Du auf jeden Fall, egal ob Du
4DOS ausprobieren willst oder nicht. Dein jetziger Versuch mit xcopy
liefert zumindest zweifelhafte Ergebnisse und Du brauchst irgendeine
andere Lösung.

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Anders herum geht es auch: Du stellst
komplett auf 4DOS um,

Deswegen meine Frage nach der Abwärtskompatibilität.

Die Optionen der einzelnen Befehle müßten identisch sein, schon alleine
aus dem Grund, weil die Entwickler das als vollwertigen Ersatz für
MS-DOS sehen. Doch je trickreicher die Batche sind, um so
wahrscheinlicher ist es, daß irgendwo Probleme auftreten. Mit etwas Pech
sind die schon unter verschiedenen MS-DOS-Versionen nicht mehr
kompatibel. Mir sind schon welche begegnet, die nur unter einer
bestimmten Sprache funktionierten. Aber da hilft letztendlich wirklich
nur ausprobieren.

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Es gibt unter 4DOS für Batch-Dateien zusätzlich noch die Erweiterung
.btm (Batch To Memory). Diese werden komplett in den Speicher geladen
und nicht wie .bat-Dateien erst während der Ausführung zeilenweise
eingelesen.
Damit kannst Du unter Windows .bat immer noch mit command.com verknüpft
lassen,

Und wie nutze ich dann in einer solchen *.bat einen 4DOS-Befehl statt
eines COMMAND.COM-Befehls?

Gar nicht, Du bzw. das System startet den Batch entweder mit command.com
oder 4dos.com und innerhalb des Batches stehen dann die Befehle des
jeweils benutzten Kommandointerpreters zur Verfügung.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Ulrich F. Heidenreich
Es sollen aber doch Batchdateien ohne Interaktivität laufen. Batches, in
denen ich laut - u.a. - Deiner Empfehlung was Besseres als das XCOPY des
COMMAND.COM nutzen könnte.

XCOPY ist ein externer Befehl, bei dem ist es egal, ob er von 4DOS oder
MS-DOS aus aufgerufen wird.

Bringt also dann keine Vorteile, wenn nicht etwa 4DOS auch ein besseres
XCOPY.EXE mitbrächte.

Meine Empfehlung für 4DOS war hauptsächlich
wegen den besseren Möglichkeiten, den Erfolg oder Mißerfolg des
Kopierens zu testen.

Das sollte aber für den Nutzer transparant in/mit genau jenem Batch
geschehen, der die Kopie auch macht.

1) Du kannst rekursiv die Unterverzeichnisse der Quelle durchlaufen und
kontrollieren, ob jeder Datei in diesem Verzeichnis auch im Ziel
vorhaden ist. Zusätzlich kannst Du auch noch Dateigröße und
Änderungsdatum vergleichen.

Mhh. Quasi ein "Chkcopy.btm", welches dem Ergebnis des DÖSigen XCOPY
auf die Finger schaut. Sollte nach einiger Einarbeitung in 4DOOS wohl
machbar sein, dürfte aber bei den bereits genannten 5319 (inzwischen
wohl noch mehr) zu prüfenden Dateinamen ziemlich dauern. Glaubst Du mir
jetzt, warum mir eine Prüfung des jeweils aktuellen "/d" (Bei 4DOS wohl
"/u") lieber ist: Das sind immer nur so um die 10 bis 40 Dateienamen.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Das sollte aber für den Nutzer transparant in/mit genau jenem Batch
geschehen, der die Kopie auch macht.

Natürlich. Du müßtest die Batchdatei überprüfen, ob sie unter 4DOS
funktioniert und ggf. anpassen. Aber wie bereits geschrieben: Irgendwie
ändern mußt Du die Datei sowieso, da sie nicht so funktioniert wie sie
soll oder Fehler meldet, die vielleicht gar nicht da sind.

Post by Ulrich F. Heidenreich

Post by Heiko Rost
1) Du kannst rekursiv die Unterverzeichnisse der Quelle durchlaufen und
kontrollieren, ob jeder Datei in diesem Verzeichnis auch im Ziel
vorhaden ist. Zusätzlich kannst Du auch noch Dateigröße und
Änderungsdatum vergleichen.

Mhh. Quasi ein "Chkcopy.btm", welches dem Ergebnis des DÖSigen XCOPY
auf die Finger schaut. Sollte nach einiger Einarbeitung in 4DOOS wohl
machbar sein, dürfte aber bei den bereits genannten 5319 (inzwischen
wohl noch mehr) zu prüfenden Dateinamen ziemlich dauern.

Ja, das dauert über das Netzwerk wahrscheinlich relativ lange.

Deshalb auch Vorschlag 2 mit "dir verzeichnis /s /b |sort >liste" und
"fc". Das Problem daran ist, daß der vollständige Dateiname in den
Listen steht und es mit DOS-/Windows-Bordmitteln (qbasic schließe ich
mal aus) wahrscheinlich nicht mögich ist, die in relativ Pfade
umzuwandeln. Das könntest Du mit 4DOS machen. Alternativ kannst Du Dir
in Pascal ein Programm schreiben, daß in Textdateien die ersten x
Zeichen jeder Zeile entfernt (wahrscheinlich gibt es das irgendwo in den
Tiefen des Internets schon) und dann die so aufbereiteten Listen mit fc
vergleichen.

Post by Ulrich F. Heidenreich
Glaubst Du mir
jetzt, warum mir eine Prüfung des jeweils aktuellen "/d" (Bei 4DOS wohl
"/u") lieber ist: Das sind immer nur so um die 10 bis 40 Dateienamen.

Das glaube ich Dir. Nur was nutzt das, wenn sich xcopy aus irgendwelchen
Gründen seltsam verhält.

Gruß Heiko

[Axel Berger]

Post by Ulrich F. Heidenreich
Bringt also dann keine Vorteile, wenn nicht etwa 4DOS
auch ein besseres XCOPY.EXE mitbrächte.

Deine Scheuklappen sind schon beeindruckend. Du möchtest ein anderes
Ergebnis, bist aber, um es zu erreichen, nicht bereit, das kleinste
bißchen anders zu machen als vorher.

Der erste, der 4DOS erwähnt hatte, war iirc ich als Antwort auf die
Frage, ob move Subdirectories beherrsche. XCOPY als separates externes
Programm wurde geschrieben, weil das interne copy von command.com zu
eingeschränkt für viele Zwecke war. 4DOS braucht kein XCOPY, sein
eingebautes copy kann selbst schon genug. Möglicherweise reicht es
allein und seine Fehlermeldungen für Dich schon vollkommen aus,
probier's aus oder laß' es bleiben.

Deine Frage nach der Rückwärtskompatibilität habe ich bisher nicht
beantwortet, weil ich keine absolute Antwort weiß. OTOH unterscheiden
sich schon die command.com der verschiedenen DOS- und Windowsversionen
in vielen Punkten und ab XP ist ohnehin alles ganz anders. Ich bin in
der Praxis noch auf keine einige für DOS und Windows bis 98SE
geschriebene Batchdatei gestoßen, die nicht gelaufen wäre. Ich wage aber
nicht zu behaupten, daß das ausnahmslos und immer so sei.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
Bringt also dann keine Vorteile, wenn nicht etwa 4DOS
auch ein besseres XCOPY.EXE mitbrächte.

Deine Scheuklappen sind schon beeindruckend.

Äh, wieso? Heiko sagte doch, XCOPY sei ein *externer* Befehl. Wenn 4DOS
dafür keinen Ersatz mitbringt, wird auch 4DOS den MSDOS-XCOPY aufrufen
und nichts wäre damit gewonnen. Zwar könnte 4DOS' "copy" - soweit ich da
reingeschnuppert habe - per "/u" da auch was reißen, dafür müsste aber,
da dies ein *interner* Befehl ist, die Shell ausgetauscht werden.

Post by Axel Berger
Du möchtest ein anderes
Ergebnis,

Nö. Eigentlich möchte ich nur Fehlermeldungen, mit denen man etwas
anfangen kann. "Befehl oder Dateiname nicht gefunden" passt auch in
diese Kiste. Warum kann das **censored** DOS nicht sagen, *welcher*
Befehl nicht gefunden wurde? Das zieht sich BTW einmal quer durchs
ganze M$-Geraffel: Das System muss ja Kriterien haben, an Hand derer
eine Fehlersituation erkannt wurde; warum zum Henker nennt es sie sie
meist nicht?

Post by Axel Berger
Deine Frage nach der Rückwärtskompatibilität habe ich bisher nicht
beantwortet, weil ich keine absolute Antwort weiß. OTOH unterscheiden
sich schon die command.com der verschiedenen DOS- und Windowsversionen
in vielen Punkten und ab XP ist ohnehin alles ganz anders.

Also das XCOPY, welches vom XP-"Videorecorder" aus die Tatorte im
Mischnetz verteilt, funktioniert genauso wie das Win95-XCOPY hier
zur Verteilung der Digitalfotos auf den WIN98SE-Wohnzimmerrechner.
Wenn da was nicht funktioniert, weiß ich, daß ich nicht auf Eigenarten
der Shell achten muss, die kenne ich. Wenn ich sie dagegen gegen 4DOs
austauschte ...

Post by Axel Berger
Ich bin in
der Praxis noch auf keine einige für DOS und Windows bis 98SE
geschriebene Batchdatei gestoßen, die nicht gelaufen wäre. Ich wage aber
nicht zu behaupten, daß das ausnahmslos und immer so sei.

Hier hängt einfach zuviel dran. Neben der ganzen Backupgeschichte (Ja,
lieber Claus: Das Backup macht der Ghost. XCOPY sorgt für Redundanz
u.a. seiner Backups), der Datenverteilung im Heimnetz, gewissen wgets
(Wetterbericht, Goldkurs) basiert auch mein UUCP hier nicht unerheblich
auf DOS-Batches.

Ein externer XCOPY (-Ersatz), der die Fehlerursache beim Namen nennen
würde, reichte schon. Die ganze Shell auszutauschen, ist mir einfach zu
kritisch. Das hat mit Scheuklappen nix zu tun.

CU!
Ulrich

[Ulrich F. Heidenreich]

Heiko Rost in <news:***@ID-23555.user.uni-berlin.de>:

Ich bin's nochmal.

Post by Heiko Rost

Post by Ulrich F. Heidenreich

Post by Heiko Rost
Dann läßt Du so wie bisher .bat-Dateien in Windows mit command.com
verknüpft und COMSPEC auf command.com verweisen.

Damit läuft aber dann der 4DOS nicht, nicht wahr?

Irgendwie verstehe ich jetzt Bahnhof.

Schau Dir bitte mal <http://invalid.de/batch-sample.txt> an.

Das ist - im Prinzip: Alles verrate ich Dir auch nicht #-) - eine der
Batchdateien, die bei jedem Booten des Rechners angeworfen wird. Nimm
mir mal des Brett vom Kopf, wie ich da statt "XCOPY" ausm COMMAND.COM
das empfohlenerweise bessere "XCOPY" des 4DOS nutzen könnne, ohne den
gesamten Batch nicht unter COMMAND.COM, sondern 4DOS laufen zu lassen.

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Das ist - im Prinzip: Alles verrate ich Dir auch nicht #-) - eine der
Batchdateien, die bei jedem Booten des Rechners angeworfen wird. Nimm
mir mal des Brett vom Kopf, wie ich da statt "XCOPY" ausm COMMAND.COM
das empfohlenerweise bessere "XCOPY" des 4DOS nutzen könnne, ohne den
gesamten Batch nicht unter COMMAND.COM, sondern 4DOS laufen zu lassen.

Neben der Antwort aus dem anderen Posting, daß sowieso beides das selbe
xcopy benutzt: Du schreibst, wenn Dein System wie bisher mit MS-DOS
startet, in der autoexec.bat nicht mehr

call datei.bat

sondern

4dos.com /c datei.bat

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Das ist - im Prinzip: Alles verrate ich Dir auch nicht #-) - eine der
Batchdateien, die bei jedem Booten des Rechners angeworfen wird. Nimm
mir mal des Brett vom Kopf, wie ich da statt "XCOPY" ausm COMMAND.COM
das empfohlenerweise bessere "XCOPY" des 4DOS nutzen könnne, ohne den
gesamten Batch nicht unter COMMAND.COM, sondern 4DOS laufen zu lassen.

Neben der Antwort aus dem anderen Posting, daß sowieso beides das selbe
xcopy benutzt: Du schreibst, wenn Dein System wie bisher mit MS-DOS
startet, in der autoexec.bat nicht mehr
call datei.bat
sondern
4dos.com /c datei.bat

Dazu müsste er voll abwärtskompatibel sein. Ob ich das Risiko wirklich
eingehen will?

CU!
Ulrich

[Heiko Rost]

Post by Ulrich F. Heidenreich
Dazu müsste er voll abwärtskompatibel sein. Ob ich das Risiko wirklich
eingehen will?

Die Frage mußt Du Dir selber beantworten. Ich kann Dir nur sagen, daß
ich den Einsatz von 4DOS/4NT als sehr hilfreich fand und IIRC seit DOS
6.x benutze. Auch jetzt ist 4NT noch die Standard-Konsole, obwohl
komplexere Batch-Dateien weitestgehend durch VBS oder Perl abgelöst
wurden.

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Dazu müsste er voll abwärtskompatibel sein. Ob ich das Risiko wirklich
eingehen will?

Die Frage mußt Du Dir selber beantworten.

Dank Deiner Mithilfe kenne ich jetzt wenigstens Grenzen und
Möglichkeiten. Zerbrich Dir also nicht weiter meinen Kopf.

Zudem ist wohl der Pfad gar nicht zu lang geworden, sondern
der vergebene Versuch, die win368.swp mit zu XCOPYren hat
wohl eine falsche Fehlermeldung nach sich gezogen.

TNX,
Ulrich

[Axel Berger]

Post by Ulrich F. Heidenreich
sondern
der vergebene Versuch, die win368.swp mit zu XCOPYren hat
wohl eine falsche Fehlermeldung nach sich gezogen.

Ich weiß jetzt nicht mehr, ob das alte copy oder XCOPY ein "alle außer"
ermöglichte, mit 4DOS geht es einfach und wird hier, in einem Batch zum
Löschen temporärer Dateien, täglich verwendet.

Axel

[Ulrich F. Heidenreich]

Post by Axel Berger

Post by Ulrich F. Heidenreich
sondern
der vergebene Versuch, die win368.swp mit zu XCOPYren hat
wohl eine falsche Fehlermeldung nach sich gezogen.

Ich weiß jetzt nicht mehr, ob das alte copy oder XCOPY ein "alle außer"

Den Schalter /H weglassen, dann kopiert er Hidden und System nicht mehr.

Seit er den Swapfile nicht mehr mitzukopieren versucht (wo er *sofort*
"will nich" meldete, auf daß man auch die verursachende Datei kannte),
ist auch die falsche "Pfad zu lang"-Fehlermeldung am Ende des gesamten
Kopiervorgangs weg.

CU!
Ulrich

[Andrej Kluge]

Hi,

Post by Ulrich F. Heidenreich
xcopy G:\*.* Q:\driveG /s /d /c /y > C:\xcgqnap.log

Ich bin nicht 100% sicher, aber ich glaube, RoboCopy ist da mächtiger und
zuverlässiger als xcopy.

In der Doku steht:

"By default Robocopy will handle file and directory path names up to almost
32,000 characters in length. If for any reason you wish to disable this
support for very long path names, use the /256 switch. This causes Robocopy
to revert to normal path name semantics, and a maximum path name length of
256 characters.
If the /256 switch is used and Robocopy encounters a path name longer than
256 characters, one of the following errors may be reported, depending on
the operation being performed on the very long path name at the time:
- The filename, directory name, or volume label syntax is incorrect.
- The system cannot find the file specified.
- The file name or extension is too long."

Ciao
AK

[Heiko Rost]

Post by Andrej Kluge
Ich bin nicht 100% sicher, aber ich glaube, RoboCopy ist da mächtiger und
zuverlässiger als xcopy.

Stimmt, läuft meines Wissens unter Windows 95 aber nicht.

Gruß Heiko

[Heiko Rost]

Post by Ulrich F. Heidenreich
Ab da wird grundsätzlich nur kopiert und
nach Kontrolle der Kopie die Quelle gelöscht.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Mal eine andere Frage: Wenn Du eine wie auch immer arbeitende
Möglichkeit hast, die Kopie zu kontrollieren, müßte Dir diese Kontrolle
doch auch eine Meldung in der Art "Datei ... wurde nicht kopiert"
liefern können?

Gruß Heiko

[Ulrich F. Heidenreich]

Post by Heiko Rost

Post by Ulrich F. Heidenreich
Ab da wird grundsätzlich nur kopiert und
nach Kontrolle der Kopie die Quelle gelöscht.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Mal eine andere Frage: Wenn Du eine wie auch immer arbeitende
Möglichkeit hast, die Kopie zu kontrollieren, müßte Dir diese Kontrolle
doch auch eine Meldung in der Art "Datei ... wurde nicht kopiert"
liefern können?

Nein, sie sollte es, tut es aber nicht, sondern meldet nur das
*irgendwas* nicht kopiert wurde. Deshalb frag ich ja hier, ob's
da eine Möglichkeit gibt herauszufinden *was genau* nicht kopiert
wurde.

CU!
Ulrich