![]() |
MICROSOFT UND DAS KOPIEREN VON Daten
Hallo,
leider macht Microschrott seinem namen doch immer wieder alle Ehre, wenn man hofft, so langsam sei es ein Betriebssystem. Zu den einfachsten Aufgaben eines Betriebssystem sollte es doch wohl gehören, Daten von A nach B zu kopieren, und zwar ohne daß ein Operator es die ganze Zeit dabei beobachtet. Nun findet Windows aber tausend Gründe einen solchen Kopiervorgang zu unterbrechen, das kopieren oder verschieben alltäglicher Datenmengen, sagen wir mal 1 bis 20 Gigabyte in einer Windowsüblichen Dateistückelung wird dabei zu einer Tortur, weil man es nicht einfach starten, ins Bett gehen und am nächsten Tag das erfolgreiche Ergebnis in Empfang nehmen kann, denn dann stellt man im günstigsten Fall fest, das der Explorer nach 10 Minuten angehalten hat, um zu fragen, ob eine bestimmte Datei denn wirklich kopiert (verschoben) werden soll. Trifft es bei einer datei von hunderttausen auf ein anderes Problem, wie z.B. mit der Länge eines Dateinamens nicht mehr klarzukommen, den es selbst, nur unter Beteiligung von Microsoftprodukten mal erzeugt hat, bricht es ganz ab, anstatt einfach wenigstens die Problemlosen 99,9% zu kopieren. Nun gibt es viele Explorerergänzungen, die aber nach ersten Tests meistens nur auf dem Explorer aufsetzen, wo der abbricht tun die das auch. Mit den Konsolenprogrammen copy, xcopy, etc habe ich auch keine guten Erfahrungen gemacht. Es ist auch nicht übermäßig schwer, das selber besser zu schreiben, hab ich aber keine Zeit zu... Deshalb eine Frage, an der mir wirklich sehr viel liegt: Kennt jemand ein Kopier -(verschiebe) tool, das es ermöglicht, vor dem Kopieren einzustellen, was mit kritischen Dateien (schreibgeschützt, System etc) passieren soll, und das, trifft es bei einer Datei auf ein problem, einfach mit der nächsten weitermacht, statt mit oder ohne Meldung unweigerlich abzubrechen? Grüsse Wolfgang |
Hast du schon an selbst programmieren gedacht? Das wäre warscheinlich eine Sache von ein paar Stunden.
|
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich persönlich nutze gerne den 'Total-Commander' (ehemals 'Windows-Commander'); zu erhalten unter ![]() |
Re: MICROSOFT UND DAS KOPIEREN VON Daten
Zitat:
Und was xcopy angeht: Da kannst du angeben, ob alle Fragen mit "ja" beantwortet werden sollen und ob bei Fehlern der Kopiervorgang fortgesetzt werden soll. Und ich möchte nicht wissen, wie viele Lunix-Anwender schon ganze Verzeichnisse verloren haben, weil sie sich in der Konsole vertippt hatten. |
@Daniel: Vielen Dank sieht gut aus, werde ich ausprobieren.
@Braincode: Ich hatte daruaf eigentlich in meinem Beitrag schon hingewiesen, denn bevor die Sache ausreichend entwickelt und getestet ist, daß ich damit auf MissionCritical Data losgehe werden aus ein paar Stunden eben schell ein bis zwei Tage, und die hab ich nicht, und ich muß die Daten jetzt in Sicherheit bringen, und nicht in vier Wochen. Außerdem, egal ob ich pro Lizenz berappe oder 2000€ pro Jahr und Entwicklerarbeitsplatz für das MSDN-Paket bleche, vom Marktfüherer erwarte ich schon, daß er Dinge kann, die schon schon DosShells wie xtree konnten, und daß man so grundlegende und selbstverständlich Dinge auch nicht mehr dazukaufen, oder mit dem entsprechenden Testaufwand im Internet zu suchen, oder selber entwickleln muß. Ich rede auch von den Windowsversionen, die behaupten für den professionellen Einsatz brauchbar zu sein, und die entsprechend kosten. @Lucky Nun, ich bin lange genug im Geschäft, um zu wissen wovon ich rede, und Dinge zuende zu denken bevor ich meckere. 1. Ich will ja nur die Option haben, beim Kopieren (Verschieben)großer Datenmengen am Anfang einstellen zu können, was bei bestimmten Konflikten passieren soll, siehe Screenshot Daniel. Wenn ich jetzt asuwähle, schreibgeschützte Dateien mitverschieben, dann meckere ich über kein Betriebssystem, das das dann auch tut. Aus einer Baumstrukturdarstellung der directories hätte ich es gerne, um die von dir erwähnten Linuskonsolenanwenderfehler zu vermneiden (xcopy, auch s.u.). Fu8nktionalitäten wie sie schon xtree unter Dos hatte, wäre voll ausreichend (ich erwarte nichts exotisches, schweres, riskantes), die Windows - fähige - versin von xtree produziert bei großen Datenmengen leider regelmäßig Schutzverletzungen, und ist seit Win95 nicht mehr weiterentwickelt worden, fällt also leider flach. 2. Der größere Punkt: Windows (2000) erzeugt in Zusammenarbeit mit anderen Microsoft Produkten Dateinamen und Pfade und arbeitet damit, und auch die Dateisystemscanner melden kein Problem, die es später nicht mehr kopieren kann, weil die angeblich -ein Beispiel, es gibt mehr - zu lang sind, und bricht beim Antreffen einer solchen Datei, aber ebenso beim Antreffen von Betriebssytemdaten: 'System Volume Information, Recycler' dann gnadenlos ab, und man muß sich dann in einem Intervallhalbierungsverfahren an die Problemdatei herantasten, bzw darumherumkopieren. Also, das sind keine Fehler, keine I/O Probleme, einwandfreier CRC, von Windows bewußt so erzeugt. Das Verhalten von Windows ist auch nicht transaktional (alles oder nichts), d.h. nochmal die Situation: Windows stellt fest ich habe hier 500 000 Dateien, die ich verschieben soll, davon sind hundert solche, die ich nicht verschieben kann (System Volume Information u.a. aber definitv keine kritischen I/O Fehler), dann gibt es keinen Grund, nach 50000 Dateien, wegen einer, die es nicht kopieren will, abzubrechen, statt einfach mit der näschsten guten weiterzumachen (wenigstens die Option vorher konfigurierbar anzubieten), die ausgelassenen dann einfach zu protokollieren, ist auch nicht gerade eine neue Idee. Und Warnungen vor dem 'Überschreiben einer Datei' hatte ich gar nicht kritisiert. Konsolenprogramme (copy, xcopy, move ): 1. Eben die von dir erwähnten Fehler bei Linuxanwendern: Dosshelloberfläche reicht, aber nur Kommandozeile nervt (bis man die bei komplexen Dateisystemen eingetippt hat) und ist mir zu Fehleranfällig, aber wenn wenigstens funktionieren würde, denn 2. auch mit denen bin ich schon gescheitert (Fehlermeldung zu viele Dateien). Das gibt mir das Gefühl, das diese Programme nur noch mitgegeben, aber nicht konsequent gepflegt werden, nach dem Motto, es ist dabei, wir kümmern uns nicht darum, wers benutzt ist selber schuld. Dieses frustierende Verhalten ist mir von allen Windowsusern, die ich in den letzten Tagen angesprochen habe, bestätigt worden, und die sind alle nicht von der Linuxfraktion, aber mindestens das, was man so gemeinhin als Poweruser bezeichnet. Grüsse Wolfgang |
Hmm,
wie lang hast du an deinen Postst getippt. Ich denk in der Zeit wär das halbe Delphi Programm schon fertig :mrgreen: Aber zum Thema, wieso musst du 500000 Dateien kopieren. Für so Sachen gibts doch wunderbar Backuptools? Gruss, Tom |
warum einfach, wenns auch kompliziert geht, ist das etwa das Motto hier?
Code:
Das ist der Inhalt einer Batch-Datei (*.BAT). Die sichert mir den ganzen Server auf eine lokale Festplatte ins Verzeichnis \f. Das /C steht für Continue bei einem Fehler, da der Server wohl hochgefahren sein muß, um zu sichern und deshalb Dateien/Programme geöffnet sind (was genau Dein Problem ist). Das /S steht für "include Subdirectories" Da dieses Programmchen ganz einfach mit ALLF aufgerufen wird, besteht wohl kaum eine Möglichkeit, es aus Versehen falsch zu starten. Desweiteren gebe ich zu bedenken, daß ohne DOS-Kenntnisse Windows schwer verständlich bleibt. Microsoft verwendet die "uralten" Sachen selber noch, obwohl sie behaupten, es werde nicht mehr unterstützt.
c:\winnt\system32\xcopy F:\*.* c:\f\*.*/S/C
|
@jelly
hmmm
Code:
Also Budgetverantwortung würdest Du auf lange Zeit bei mir wohl nicht bekommen:
wie lang hast du an deinen Postst getippt. Ich denk in der Zeit wär das halbe Delphi Programm schon fertig
1. Ich erwarte das Windows auch große Dateimengen kopieren kann, und ich es nicht selber schreiben muß, ok, das Posting war mein "Privatvergnügen", 2. Kann Windows das nicht, versuche ich ein preiswertes Programm zu finden, das das schon kann, bevor ich es selber schreibe, um nicht alles testen zu müssen, die Anfrage. 3.Muß ich es selber schreiben, muß das Programm narrensicher sein, auch Kollegen müssen damit umgehen können, und wieviel Arbeit ist es, da Programm mit jeder Windowsversion zu testen, und dafür zu sorgen, daß es mit jedem auch zukünftig installierten Computer auch zur Verfügung steht. Ich fürchte Du verwechselst hier schnell mal ein paar zeilen Code zu schreiben, die kopieren können, mit dasselbe einmal als alltagstaugliches Programm, inclusive des Zeitbudgetrisikos, daß es irgendetwas gibt, was nicht auf Anhieb funktioniert, eine Funktion die man nicht auswendig weiß und nicht sofort findet, etc Wenn Du dich allerdings nie verschätzt, und Deine Programme immer in der Anfangs gschätzten Zeit ohne Wenn und aber fertig sind, dann verneige ich mich in Ehrfurcht, und schick mir deine berwerbungsunterlagen... -:) 4. Ich hätte es eben nicht in der zeit schreiben können, weil der Computer mit der Delphiinstallation versuchte Dateien zu kopieren. Zitat:
@Hansa Nun, die DOS-Oberfläche ist mir wihlbekannt, Batch Dateien schreibe ich normalerweise dann, wenn bestimmte dinge häufig ausgeführt werden müssen, muss man in einer Ausnahmsituation ganz schnell mal einen guten Platz finden, an den man Dateien verschieben kann, ist die grafische Oberfläche schon etwas weniger Fehleranfällig, als ein ganz schnell hingeschriebenes Batch. Ist das Batch mal fertig, ist es natütlich nicht mehr gefährlich, für häufig durchzuführende Vorgänge verwende ich diese Technik auch, trotzdem, das Gefühl vor unerwarteten Überraschungen sicher zu sein, hatte ich bei den DOS-Befehlen nicht, aus eigenen Erfahrungen, deshalb hatt ich mal nachgefragt. |
Woki, ich versteh das hier jetzt nicht. Aber mir kommt es so vor, als würdest Du Betriebssystem mit Benutzeroberfläche verwechseln.
Wem nützt es was, wenn man Dateien kopieren will, einen DOS-Befehl auszuführen, bzw. dasselbe mit windows zu tun, den Befehl genauso auszuführen, nur mit dem Unterschied zusätzlich in einer (überflüssigen) Trackbar, statt "55%" einen Balken angezeigt zu bekommen. Zitat:
Zitat:
Zitat:
Zitat:
|
Zitat:
50 MB von A nach B kopieren.
Code:
Das Archiv kann man zwar später wieder löschen, aber fakt ist dass man erst mal den Speicher zsätzlich braucht.
50 MB (A)
50 MB (B) 25 MB (Archiv) --------------- 125 MB |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz