none
Robocopy bleibt mit FEHLER 32 (0x00000020) stehen RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hi Community,

    ich synchronisiere jede Nacht zwei Fileserver miteinander und benutze dabei Robocopy mit folgenden Optionen:

    *.* /NDL /NFL /TEE /S /E /COPYALL /DCOPY:T /SECFIX /PURGE /MIR /ZB /NP /XJ /MT:16 /R:1 /W:1

    Sporadisch jedoch bleibt das Skript an Stellen stehen, wo eine Datei in Gebrauch ist:

    2018/01/09 20:24:35 FEHLER 32 (0x00000020) Folgende Datei wird kopiert \\192.168.1.2\e$\CHEF_ARCHIV\2014.pst
    Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. 0%

    Das ganze ist nachvollziehbar, anscheinend war das Outlook, welches die PST Datei eingebunden hatte noch geöffnet. Macht nichts, kann er ja auslassen, soll das System halt es morgen nochmal versuchen. Mit den Schaltern Retry:1 und Wait:1 (/R:1 /W:1) dachte ich das ganze kurz und schmerzlos abzuhaken. Leider ist dem aber nicht (immer) so. Das Skript bleibt an dieser Stelle stehen und zwar solange bis die Abbruchbedingung von 12 Stunden Laufzeit eingetreten ist. Normalerweise benötigt das Skript weniger wie zwei Stunden. Alle darauffolgenden Punkte des Skriptes werden danach natürlich nicht mehr ausgeführt.

    Kann mir jemand einen Tipp geben, wie ich verhindern kann, dass Robocopy bei einem Problem sich an einer Datei festbeißt?

    Thx & Bye Tom


    Donnerstag, 11. Januar 2018 12:34
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Thomas,

    Du musst Robocopy mit Adminrechten und im Backup Mode ausführen, dann werden auch geöffnete Dateien kopiert. Zusätzlich die Option /b mit angeben.

    https://technet.microsoft.com/de-de/library/cc733145(v=ws.10).aspx

    Ob die Kopie dann etwas Wert ist hängt vom Dateitypen ab. Eine geöffnete PST Datei enthält ein Flag, das beim Öffnen durch Outlook gesetzt wird und beim Beenden von Outlook wieder entfernt wird.

    Wird eine PST nicht korrekt beendet, muss diese repariert werden.

    In jedem Fall sollte Dein robocopy /b durchlaufen.

    Gruß Malte

    Samstag, 13. Januar 2018 13:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Malte,

    >Du musst Robocopy mit Adminrechten und im Backup Mode ausführen, dann werden auch geöffnete Dateien kopiert. Zusätzlich die Option /b mit angeben.

    Laut Doku inkludiert die bereits verwendete Option /ZB bereits den Backup Modus:

    ---snip---

    /zb - Uses Restart mode. If access is denied, this option uses Backup mode.

    ---snap---

    Mit Adminrechten wird das Skript ausgeführt. Das ist so im Taskscheduler hinterlegt.

    Thx & Bye Tom

    Montag, 15. Januar 2018 09:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Thomas,

    die Option /zb hatte ich in Deinem Posting übersehen.

    Trotz der Optionen /R:1 /W:1 bleibt robocopy stehen? Bei allen Dateitypen oder ausschließlich bei PST-Dateien?

    PST-Dateien haben ein etwas anderes Verhalten als ein Word Dokument, denn neben der Sperrung auf Dateiebene hat Outlook noch innerhalb der PST Datei die Hand drauf. (Das ist auch der Grund warum PST Dateien auf Netzlaufwerken für direkten Zugriff durch Outlook nicht unterstützt wird)

    Der Backup Modus von Robocopy kann "nur" die Sperrung auf Dateiebene umgehen.

    Gruß Malte

    Dienstag, 16. Januar 2018 13:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Malte,

    >Trotz der Optionen /R:1 /W:1 bleibt robocopy stehen? Bei allen Dateitypen oder ausschließlich bei PST-Dateien?

    Mit der og Fehlermeldung ist Robocopy zuletzt zweimal an dieser PST stehen geblieben. Die anderen Vorfälle, die ich noch aus den Logfiles kramen konnte, waren .doc und .pdf Dateien aber ohne jede Fehlermeldung. Das Log hört mit einer unbestimmten Anzahl an 100% 100% 100% Einträgen auf. Würde ein Fehler ein Weiterspringen zur nächsten Datei verursachen, stünde das am Ende des Logfiles als Fehlermeldung.

    Wir hatten solche Vorfälle lange Zeit nicht aber seit letzten Jahr tritt das immer wieder mal auf (ca. 5x in den letzten zwei Monaten)

    Thx & Bye Tom

    Dienstag, 16. Januar 2018 13:59
    |