|
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  www.ghisler.com. Du kannst dort wie gewünscht _vor_ dem Kopiervorgang einstellen, wie das Programm reagieren soll (s. angehängter Screenshot) |
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 |
Aber doch nur für eine geringe Zeit.
|
Wenn ich den Speicherplatz nicht habe spielt die Zeit wohl keine große Rolle.
|
wenn dem so ist, dann frage ich mich, welche Budgets zur Verfügung stehen, falls nicht mal die Festplatte groß genug ist. 8)
|
:o :cry: :o :cry: :o :cry:
Zitat:
Ob ein aus der Konsole ausgeführtes xcopy sich technisch nur in den Optionen von dem aus dem Explorer ausgeführten Copy unterscheidet, und ansonsten vollständig auf den gleichen Systemroutinen aufsetzt, wie es vielleicht sein sollte, das wage ich mir bei Microsoft nicht sicher zu sein, aber wenn du sagst, daß das so ist, ist es fraglich, ob mir das xcopy wie behauptet geholfen hätte. Zitat:
Zitat:
Zitat:
Wie war das mit dem Lesen und dem Vorteil? Zitat:
Zitat:
Führen wir mal einen kleinen Beweis: geggeben n Dateien mit Platzbedarf M1 im Dateisystem umd M2 im Archiv. Meinetwwegen, obwohl total egal, Archiv ist komprimiert, also M2 < M1. Bei Verwendung eines komprimierten NTFS Dateisystems ist M2 nur wenig kieiner M1, ist aber wie gesagt egal!!!! Aufgabe: Speicherplatzbedarfsbestimmung damit Dateien von A nach B kopiert werden können: 1. Platzbedarf kopieren erfordert Plats M1 auf Platte 1 und M1 auf Platte 2, also Gesamt bei kopieren Mk = 2* M1 2. Verwendung Backuptool, also kopieren von Platte 1 in Archiv, und dann auspacken nach Platte 2, wie vorgeschlagen, erfordert M1 auf Platte 1 und M1 auf Platte zwei, und M2 irgendwo für das Archiv, also gesamt bei Backuptoollösung: MB= M1(auf platte 1) + M2(irgendwo für Archiv) + M1 (auf Platte 2 für wiederauspacken, die Dateien sollen ja im Dateisystem zur Verfügung stehen, aber nicht auf Platte 1, die soll nämlich plattgemacht werden.) Behauptung: Mk < Mb Beweis: Mk < Mb <=> M1 + M1 < M1+M2+M1 <=> 0 < M2 quod erat demonstrandum weil M2 aus der Menge der natürlichen Zahlen. <=> steht für äquivalent, und ich muß das aber bitte nicht definieren, oder? Wenn wir uns also daruf einigen können, daß die größe des Archivs einen Wert hat, der echt größer Null, ist meine Behauptung bewiesen. Mann kann das allerdings normalerweise auch ohne Beweis auf den ersten Blick erkennen. Zitat:
Nachdem das Batch einmal fertig ist, brauche ich natürlich kein Icon, um es wiederzuerkennen, aber es ging auch nicht um automation wiederkehrender Aktionen, sondern um einmalige Aktionen in Ausnahmesituationen. |
@Luckie,
danke erstmal für deine Schützenhilfe, da fühlt man sich wenigstens etwas verstanden, es ging jedoch nicht um 50MB sondern um 50GB, das resultierte aus einem nicht geplanten Notfall, sollte abends um neun gestartet werden und am nächsten morgen fertig sein, und da finde ich es OK, das ich gerade noch 50 GB spontan zur Verfügung hatte, aber z.B. nicht 90GB, den ich glaube nicht das der komprimierungsgewinn im Vergleich zum komprimierten NTFS mehr als 20% ist, also 40 GB Archiv statt 50GB. Wo Du Hansa) in Deutschland abends um 9 noch gerade mal eine Platte herbekommst, das würde mich mal interessieren, oder hättest Du mir noch schnell eine vorbeigebracht? Außerdem verbraucht der Archivierungsweg auch mehr Arbeitszeit: Stichwort Budget und Verfügbarkeit: Abends start Archinvierung, morgends start auspacken, Verfügbarkeit am neuen Platz frühestens am abend des nächsten Tages statt am morgen etc , etc etc etc Ich hätte nicht erwartet, daß man dass alles so breit erklären muß. Grüsse Woki. |
Jungs, ganz ehrlich (Mädels haben sich ja in diesem Thread noch nicht beiteiligt),
Ich versteh irgendwie nicht die ganze Diskussion. Das Problem ist, wie Hansa bereits geschildert, mit einer Zeile Batch-Code gelöst :P Also Woki, hast du die Lösung schon mal ausprobiert, oder nur in der 20 Jahre Dos Geschichte dir den Befehl mal angekuckt. xcopy macht doch genau das was du willst. Wenn dir das zu kompliziert ist für deine User, dann pack den Befehl in ein schönes Delphi Programm rein und fertig. Willst du nicht über die DOS Ebene fahren, dann such dir die zu kopierenden Datein selbst rekusrsiv raus und kopier sie halt. Die möglichen Kopierfehler kannst du doch leicht abfangen. Ich versteh ehrlich einfach nicht, was daran so kompliziert ist und wieso da immer wieder Gegenargumente von Woki aufgebracht werden. Meines Achtens ist das ein Delphi Programm das sicherlich ziemlich bugsicher in 2 Stunden da steht, von jedem DAU leicht zu benutzen. Man kann kompliziert und stundenland über ein Problem diskutieren, oder es einfach auf die einfachste Art und Weise lösen. Und Woki, ich will und ich werd dein Budegt nicht verantworten, denn ich glaub das gäb früher oder später böses Blut. Aber ich bin mal gespannt auf die Fortsetzung dieses Threads, denn die ist sicherlich interessanter als das Thema an sich. Gruss, Tom |
Zitat:
Zitat:
Ich schließe das mal hier. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 15:50 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