none
Migration XCOPY /D RRS feed

  • Frage

  • Hallo,

    ich bin auf der Suche nach einer Umsetzung von "XCOPY [...] /D" nach PowerShell (also Kopieren von Dateien, wenn sie im Zielordner entweder nicht existiert oder dort älter ist, als im Quellordner). Bei Copy-Item habe ich keine Möglichkeit gefunden. -Filter hat mich angelächelt, aber was damit anstellbar ist habe ich noch nicht verstanden.

    Oder muss ich das "zu Fuss" lösen (Dateidatum auf beiden Seiten ermitteln und vergleichen)?

    Bitte keine Lösungen mit irgendwelchen Zusatz-Werkzeugen.

    Zusatzfrage: Copy-Item "C:\foo\bar.txt" "C:\foo\bar2.txt" überschreibt bei mir eine alte bar2.txt. Nach meinem Verständnis sollte das nicht so sein, wenn -Force nicht verwendet wird. AN irgendwelchen Statdardparametern habe ich nicht gedreht. Was habe ich übersehen?

    Vielen Dank im Vorraus



    • Bearbeitet Ifm001 Dienstag, 19. August 2014 10:45 typo
    Dienstag, 19. August 2014 10:43

Antworten

  • Hallo,

    du kannst z.B: auch direkt mit der System.IO.File Klasse arbeiten.

    [System.IO.File]::Copy("E:\Scripte\zzz.txt","E:\Scripte\yyy.txt")
    In dem Fall bekommst Du einen Fehler wenn die Datei yyy.txt vorhanden ist, d.h. sie wird nicht einfach ueberschrieben.

    Und so wuerde sie dann ueberschrieben werden.

    [System.IO.File]::Copy("E:\Scripte\zzz.txt","E:\Scripte\yyy.txt",$true)

    Beste Gruesse
    brima

    Freitag, 22. August 2014 12:38

Alle Antworten

  • Hi,

    müssen es zwingend Powershell-Befehle sein? Du kannst innerhalb einer Powershell auch xcopy weiterhin verwenden (per "cmd /c <Befehl>") oder Du steigst auf robocopy um. Letzteres ist sicher die bessere Wahl, weil viel mehr Optionen und stabiler.

    Gruß

    Ben

    Dienstag, 19. August 2014 10:53
  • Hallo Ben,

    genau das meinte ich mit "Bitte keine Lösungen mit irgendwelchen Zusatz-Werkzeugen."

    Ich möchte halt gerne erstmal den "sauberen In-House"-Weg kennen. AFAIR machen solche "Krücken" mittelfristig oft Probleme, die dann auch noch schwer darauf zurückzuführen sind.

    In meinem Fall kommt ja noch hinzu, dass das Auslesen der Dateierstellungs-Daten und deren Vergleich auch nicht so schwer umsetzbar ist. Ich wollte halt nur wissen, ob es einen besseren/anderen "In House"-Weg gibt.

    Trotzdem natürlich danke für deine Antwort.
    • Bearbeitet Ifm001 Dienstag, 19. August 2014 11:53
    Dienstag, 19. August 2014 11:51
  • Sorry, den Satz hab ich total überlesen... :-O :-)

    Schau Dir das mal an...

    http://blogs.technet.com/b/heyscriptingguy/archive/2012/02/23/use-powershell-to-back-up-modified-files-to-the-network.aspx

    Vielleicht bringt Dich das ein Stück weiter.

    Zusatzfrage: So, wie ich die Beschreibung des Parameters "Force" interpretiere, ist der wohl nur für schreibgeschützte Dateien usw. gedacht. Normale Dateien werden wohl immer überschreiben, d.h. man muss sich wohl eine komplizierte Schleife aus Abfragen und dann-doch-nicht-kopieren basteln.

    Wenn ich das alles sehe, hättest Du es mit einem simplen Robocopy wesentlich einfacher... sauberer als ein Einzeiler geht es wirklich nicht. :-) Mit PowerShell musst Du für das gleiche Ergebnis in diesem Fall einen wesentlich höheren Aufwand betreiben.

    Gruß

    Ben

    Dienstag, 19. August 2014 12:05
  • Ich versteh nicht ganz, was gegen XCOPY oder, besser, ROBOCOPY spricht: Robocopy ist ein richtig gutes Tool, schnell, stabil, kann viel.

    Warum willst Du das umständlich mit Posh nachbilden?
    Es sei denn, Du willst den Output, das Kopier-Ergebnis weiterverarbeiten, dann ist Posh mit seinen Objekten natürlich wesentlich besser als den Text-Output von Robocopy zu parsen.

    Walter

    Dienstag, 19. August 2014 14:28
  • Ein paar Gründe habe ich  ja schon genannt (siehe Antwort an Ben). Aber ich kann es gerne noch weiter ausführen:

    1. Bei Verwendung von externen Tools ist eine später mal auftretende Fehleranalyse schwer. Bestenfalls(!) gibt es einen Errorlevel zurück. Man muss sich weitestgehend darauf verlassen, dass die gewollte Zustandsänderung geklappt hat.
    2. Das externe Tool muss auf allen betroffenen Clients verfügbar gemacht werden und die nötigen Berechtigungen vorhanden sein. Bei mit Windows mitgelieferten Tools ist die Frage, ob es auch noch in der nächsten Version dabei ist (Bei XCOPY ist eine Entfernung gar nicht so unwarscheinlich. Immerhin soll PowerShell eine Ablösung für cmd und den dazugehörigen Tools sein ... und in dem Kontext finde ich es ganz schön abstrus XCOPY von PowerShell aus zu benutzen). Ganz blöd wird es, wenn die Richtlinien des Unternehmens dagegen sprechen ... und diese Richtlinien verschärfen sich mit der Zeit, so dass eine heute funktionierende Lösung morgen Probleme bereiten kann.
    3. Ich brauche meine In-House-Lösung nur in einer Prozedur kapseln, diese allgemeiner auslegen und ordentlich (im Sinne Fehlerbehandlung, Wartbarkeit usw.) umzusetzen und schon habe ich ein robuste Lösung für die nächsten x Fälle.
    4. Ich möchte verstehen wie mein verwendetes Tool (hier Powershell) tickt. Für mich ist eine Problemstellung nicht nur zu lösen, sondern der auch immer ein "Lehrgang" --> bin halt Hardcore-Autodidakt.
    5. Für das hier angesprochene Problem ist eine In-House-Lösung ja nicht besonders aufwendig. Ich wollte bloss wissen, ob es ggf. einen eleganteren Weg gibt.

    • Bearbeitet Ifm001 Freitag, 22. August 2014 10:39
    Freitag, 22. August 2014 09:27
  • Hallo,

    ja das musst Du dann schon alles zu Fuss machen, wenn Du es wegen deiner Begruendung nicht mit einem Tool machen willst.

    Der Copy-Item kann "wenig", was du ja auch an deiner -Force Problematik siehst. Copy-Item ueberschreibt standdardmaessig bereits vorhandene Dateien. Willst du dasss nicht musst du auch in dem Fall die Fuesse bewegen, den es gibt keinen Parameter mit dem du das verhalten beinflussen kannst, sondern du muesset z.b.: vorher mit Test-Path pruefen, ob am Ziel schon ene Datei vorhanden ist, und je nach dem genauer prufen z.b: mit Get-ChildItem ob die Datei am Ziel aelter ist usw.

    -Force ist dafuer gedacht, z.B.: Dateinen ohne nachfrage zu ueberschreiben, die ein Read-Only Attribut haben.

    Ich benutze RoboCopy was auch deutlich schneller arbeitet wie copy-item. Ich kann aber wie gesagt deine Gruende verstehen, warum du das nicht willst. Somit musst du dann aber leider all das selber bauen, was die Tools so bieten.

    Beste Gruesse
    brima

    Freitag, 22. August 2014 12:29
  • Hallo,

    du kannst z.B: auch direkt mit der System.IO.File Klasse arbeiten.

    [System.IO.File]::Copy("E:\Scripte\zzz.txt","E:\Scripte\yyy.txt")
    In dem Fall bekommst Du einen Fehler wenn die Datei yyy.txt vorhanden ist, d.h. sie wird nicht einfach ueberschrieben.

    Und so wuerde sie dann ueberschrieben werden.

    [System.IO.File]::Copy("E:\Scripte\zzz.txt","E:\Scripte\yyy.txt",$true)

    Beste Gruesse
    brima

    Freitag, 22. August 2014 12:38
  • Hallo Ifm001!

    Ich kann dir mehrere Gründe nennen warum man das nicht mit PowerShell machen sollte.

    Lies bitte mal dazu meine Blog Artikel hier:
    http://www.powershell-group.eu/datei-backup-oder-synchronisation-mit-der-windows-powershell/

    Damit du das aber trotzdem in PowerShell umsetzen kannst, kann ich dir den PowerShell Robocopy Clone von Ingo Karstein empfehlen:

    https://robopowercopy.codeplex.com/

    Der Robocopy clone ist halt etwas Langsam, da er mit .NET umgesetzt worden ist.

    Alternativ kannst du auch die .NET Befehle der Library QuickIO.NET  nutzen.

    QuickIO.NET ist eine Bibliothek (*.dll) mit dem Fokus auf die performante und komfortable Interaktion mit Dateien, Verzeichnissen und Metadaten auf dem lokalen wie auch über das Netzwerk verbundene Dateisysteme.

    https://quickio.codeplex.com/


    PowerShell Artikel, Buchtipps und kostenlose PowerShell Tutorials + E-Books
    auf der deutschsprachigen PowerShell Community

    Mein 21 Teiliger PowerShell Video Grundlehrgang
    Deutsche PowerShell Videos auf Youtube
    Folge mir auf:
    Twitter | Facebook | Google+

    Montag, 25. August 2014 08:52