Ordner benennt sich einfach um - seltsames Datenrouting

Hallo Leute,

ich habe ein interessantes Problem! Zwei PC im Heimnetzwerk. Einer W8.1 und einer W7 Home. Vom W8.1 PC sollen Daten auf den anderen kopiert werden. Auf einer Datenplatte des W7 PC wird ein Ordner Daten angelegt und über robocopy werden dorthin die üblichen Datenordner wie Dokumente, Bilder, Music usw. aus dem Profil des W8.1 PC hin kopiert. Der Zielordner heißt dann plötzlich Dokumente aber wenn man wieder einen neuen Ordner Daten anlegen will heißt es ein solcher Ordner sei schon da. Auf dem Quell PC läuft robocopy etliche Minuten und meldet das Kopieren. Es kommen aber keine Daten an. Dann Neustart. Anschließend geht man zu dem Zielordner - da heißt der plötzlich wieder Daten, aber es wirklich nichts drin. An der Syntax kann es nicht liegen, habe alle Varianten mit/ohne Backslash und mit /ohne Anführungszeichen usw. ausprobiert. Immer das gleiche.

Da so etwas ja eigentlich nicht erklärbar ist, habe ich chkdsk in allen Optionen genutzt- es wurden keine Fehler erkannt.

Auf dem W7 PC läuft aber alles, wenn auch manchmal Probleme bei der Verbindung zum anderen PC in Form einer Verzögerung auftreten. IPv4 und 6 sind einwandfrei konfiguriert.

Kann das der SATA Controller sein?

Bin für jedes Brainstorming dankbar.

Lorei

im Quellordner befindet sich eine Datei namens Desktop.ini, diese bestimmt ua. den Ordnernamen im Explorer-Fenster.

Interessante Info! Danke.

Könnte das bedeuten, dass dadurch robocopy irrtiert wird? Eher doch nicht, denn intern muss der Ordner doch weiterhin Daten heißen. Wenn aber doch eine Irritation auftreten sollte, müsste ja zumindest alles aus dem Ordner Dokumente übernommen werden. Dass aber gar nichts ankommt erklärt das doch leider nicht?

Lorei

Wahrscheinlich landet die Desktop.ini des Dokumentenordners im Datenordner und deshalb erhält der Ordner den anderen Namen. Darauf wollte @frogger9 mit Sicherheit aufmerksam machen. Nimm deshalb die Desktop.ini generell von der Sicherung aus - dann dürfte das nicht mehr passieren.

Ich würde gerne dazu Bilder von den CLI Befehlen und dem Ergebnis hinterher sehen, bin mir nicht sicher, ob ich deiner Beschreibung ganz folgen kann.

Versuch es vielleicht mal hinten an den Befehl zu setzen.

Die Option /XF: wird bei robocopy beschrieben als
/XF Datei[Datei]:: Schließt Dateien aus, die mit den angegebenen Namen/Pfaden/Platzhaltern übereinstimmen.

Greift das wirklich die Desktop.ini raus? Einen solchen Schalter habe ich noch nie genutzt und werde es natürlich morgen Früh sofort probieren.

Logisch wäre dieses Bild ja schon irgendwie. Die Desktop.ini fliegt ein, benennt den Ordner um und robocopy kopiert dann ins Nirwana? Eine Fehlermeldung zum Kopieren kommt jedoch nicht. Als Schalter ist aktuell /mir eingesetzt, der müsste ja eigentlich ein Mirroring erzwingen?

Was ist dann wenn ich beide Schalter verwende? Wie gesagt, kann erst morgen ausprobieren.

Lorei

Ja, habe ich gestern und vorgestern selbst genutzt, weil es bei der Desktop.ini immer hängen geblieben ist.
Du schreibst die Schalter einfach nacheinander weg, mit Leerzeichen.
Also ich nutze neben /MIR Robocopy auch immer mit /R:3 und /W:3, so wird eine gerade nicht kopierbare Datei (z.B. durch geöffnet gesperrt) 3x alle 3 Sekunden versucht zu kopieren. Standardwert bei R ist sonst 1 Millionen und bei W 30 Sekunden. Also 30.000.000 Sekunden will ich dann halt doch nicht warten. Sieht dann so aus:

Toller Tipp! Vielen Dank, werde ich probieren.

Fragt sich nur, was hat dann robocopy die Viertelstunde getrieben, die die Kopien gedauert haben ohne das was im Ordner verblieb. Vermutlich hat jeweils die desktop.ini im jeweiligen Quellordner die Kopien sozusagen weg geleitet. :-)

Damit muss ich aber wohl nicht mehr die Hardware (Controller) zum Waterboarding schicken, die sind wohl unschuldig?

Lorei

Die desktop.ini benennt den Ordner nicht um, sondern lässt ihn im Explorer nur anders anzeigen. Die hat also keinen Einfluss auf robocopy.
Wenn du robocopy in der Konsole ausführst, solltest du auch sehen, wo es hängt.

Die Konsole machte ja den Eindruck, als würde alles laufen? Es kam immer die übliche Ausschrift : Neue Datei Datei Kopiert. Nur im Ordner war anschließend nichts. Allerdings hatte ich mal während des Kopiervorganges in den maskierten Zielordner geschaut - und sah dort Dateien einfliegen. Wie dann alles fertig war hieß der Ordner wieder mit dem vergebenen Namen - war aber leer.

Mit einer Netzproblematik ist das sicher nicht erklärbar und mit einem Controller/Treiberproblem ja wohl eher auch nicht. Die Dateistruktur hatte ich auch geprüft. Es bleibt also das Rätsel was wohin kopiert wurde und wo es dann abblieb.

Ich grübel ja auch drüber. In der Syntax hatte ich die Zeilen so geschrieben:

robocopy c:\User\Username\Documents \\FremdPC\e\Sicherung\Username\ /mir

e war eine Freigabe, ich hatte es aber mit einem direkt adressierten Ordner versucht- gleiches Ergebnis. Jetzt bleibt mir nur noch die Vermutung, dass ich für jeden Zielordner immer den gleichen Namen wie in der Quelle hinzuschreiben könnte um die Desktop. ini nicht zu übergehen?

Lorei

Versuch' es anstatt mit /MIR mal mit /E

Danke für die Anregung, aber /e heißt doch

/E :: Kopiert Unterverzeichnisse, einschließlich leerer Unterverzeichnisse.

Damit käme aber leider kein Mirroring zustande und das sei hier das Ziel. Leider komme ich nun doch erst Montag dazu diese Anregungen alle mal auszuprobieren.

Lorei

Aber damit kannst du testen, ob deine Daten alle erhalten bleiben.