Delphi-PRAXiS - MICROSOFT UND DAS KOPIEREN VON Daten

:o :cry: :o :cry: :o :cry:

Zitat:

Woki, ich versteh das hier jetzt nicht. Aber mir kommt es so vor, als würdest Du Betriebssystem mit Benutzeroberfläche verwechseln.

Ich kann das auseinanderhalten.
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:

Das zweite Wort hier hat einen faden Beigeschmack. Das wurde von vielen Versicherungs-Vermittlerrn zweckentfremdet.

Zitat:

Hääääääää????????
Budgetveratntwortung = Verantwortung dafür, wofür Geld ausgegben wird, schließt auch die Verwendung interner Arbeitszeit mit ein, unter berücksichtigung aller Folgeskosten (bei Geräteanschaffungen auch gern als tco, Total Cost of Ownership bezeichnet)

Desweiteren würde ich mein Budget eher für eine Zeile BAT-Code ausgeben, anstatt für einen Windows Balken.

Wieso, wer braucht einen Windowsbalken, es geht darum aus einem Dateibaum in einem komplexen Dateisystem schneller und mit geringerer Fehlerwahrscheinlichkeit Dateien auswählen und Ziel festlegen zu können. Wir wollen doch hier nicht zu einer Grundlagendiskussion über die Frage kommen, warum erst Dosshells (xtree, Norton Commander) und dann grafische Benutzeroberflächen erfunden worden sind, und wann sie effizienter und weniger fehlerträchtig sind als Textkonsolen.

Zitat:

Dann lieferst Du Dich dem aus, ders gemacht hat, keine gute Lösung.

Die klassische Make or Buy entscheidung, was man kaufen kann, sollte man nicht selber machen, jedenfalls nicht im Job, grundlegende Erkenntnis, und zum Beispiel grundlegende Motivation zu Erfindung von Komponenten (Prinzip der Wiederverwendung, auch durch andere)

Zitat:

Machs lieber selber, selbst wenns unnötig ist, wie hier. Die eine Zeile Code steht in dem Thread bereits drin.

Hatte ich schon erwähnt, daß mir die Konsolenbefehle copy, xcopy, move (s.o.) bekannt sind, und ich weiß auch, wie man sie hinschreibt. Was Zeit kostet ist nicht einen Befehl hinzuschreiben, dessen Syntax seit ca 20 Jahren bekannt ist (bitte jetzt nicht wieder über 20 oder 30 Jahre streiten), sondern stunden später die Erkenntnis, daß es nicht geholfen hat.
Wie war das mit dem Lesen und dem Vorteil?

Zitat:

woki hat folgendes geschrieben:

on a -> archiv, archiv -> b mag zwar eventuell als Notlösung funktionieren, verdoppelt aber den benötigten Zeitaufwand, und erhöht den benötigten Plattenplatz um 50%

Zitat:

Komprimieren erhöht den Speicherplatz? no Comment.

Oh man, dazu kann ich mir nen Kommentar jetzt aber nicht verkneifen, vielleicht einfach mal lesen, dann denken, dann schreiben, oder mache ich wirklcih den Eindruck als könnte ich nicht 1+1 rechnen, wäre vielleicht gut zu wissen.
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:

Was für Dich DOS-Befehle sind, sind Windows Befehle und deshalb sehr fehleranfällig. Der Unterschied ist vielleicht, daß Du dafür eventuell ein Icon erstellen müßtest. Halt für die DAUs. Schau Dir mal die Konsolenbefehle an.

Ok, das verstehe ich jetzt nicht, ok, ich sollte sauberer formulieren, die Windowshilfe spricht dort von einen DOS-Teilsystem und Befehlszeilenfunktionen, das xcopy aus der Konsole nicht mehr der 8.3 Dateinamenskonvention etc gehorcht, war mich schon klar.

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.