MICROSOFT UND DAS KOPIEREN VON Daten

[Hansa]

Aber doch nur für eine geringe Zeit.

[Luckie]

Wenn ich den Speicherplatz nicht habe spielt die Zeit wohl keine große Rolle.

[Hansa]

wenn dem so ist, dann frage ich mich, welche Budgets zur Verfügung stehen, falls nicht mal die Festplatte groß genug ist. 8)

[woki]

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.

[woki]

@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.

[Jelly]

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

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

[Luckie]

Zitat von woki:

es ging jedoch nicht um 50MB sondern um 50GB

War doch nur ein Beispiel.

Zitat:

Ich hätte nicht erwartet, daß man dass alles so breit erklären muß.

Und ich weiß nicht, warum du dich hier bei uns in einem Delphi-Forum über Microsoft ausheulst.

Ich schließe das mal hier.