Win10 und TortoiseSVN Datei kopieren funktioniert nicht

[Codehunter]

Hallo!

Ich habe hier ein ganz merkwürdiges Phänomen:

(1) Lokal auf Festplatte habe ich eine Unit. Die will ich auf das NAS kopieren. Zielpfad auf dem NAS ist ein UNC-Pfad. Dort liegt bereits eine ältere Version der selben Unit. Ich öffne zwei Explorerfenster, eins mit dem lokalen und eins mit dem NAS-Pfad. Dann ziehe ich die Unit von Lokal auf Remote. Der Explorer fragt "Datei exisitiert schon, soll ich überschreiben?" und ich sage JA. Es erscheint der Traffic-Graph/Fortschrittsanzeige von Windows 10 und alles macht den Eindruck, die Unit wäre kopiert worden. Jedoch, auf dem NAS ändert sich weder das Dateidatum noch der Inhalt der Unit. Es bleibt dort die alte Version. Mache ich genau das selbe ein zweites Mal, dann wird die Unit auf dem NAS ersetzt.

(2) Jetzt kommts noch dicker: Gehe ich an einen anderen Rechner und versuche die Unit vom NAS auf die dortige lokale Platte zu kopieren, dann passiert genau das selbe. Auf dem Zielrechner bleibt die ältere Version erhalten, die dann unter Umständen sogar noch älter ist als die Version, die vor der ganzen in (1) beschriebenen Aktion auf dem NAS lag.

Die üblichen Verdächtigen wie Virenscanner und Volumeschattenkopie habe ich schon mal ausgeschlossen. Das einzige das mir einfiele, ist TortoiseSVN. Denn die lokalen Pfade auf den beiden Rechnern sind jeweils SVN-Projektordner. Dass da beim Drag&Drop evtl. irgendeine ältere Version rausgekramt wird? So komisch wie es klingt. Ich bin mit meinem Latein echt am Ende.

Viele Grüße
Cody

Edit Titel geändert

[dummzeuch]

Zitat von Codehunter:

Die üblichen Verdächtigen wie Virenscanner und Volumeschattenkopie habe ich schon mal ausgeschlossen.

Welches Betriebssystem läuft auf dem NAS? Meine Vermutung: Ein Linux mit Samba. Da kommt sowas manchmal vor. In der Regel hilft ein Neustart von Samba oder wahrscheinlich einfacher, des NAS.

Schattenkopie dürfte auf dem NAS keine Rolle spielen, wenn es ein Linux ist.

Zitat von Codehunter:

Das einzige das mir einfiele, ist TortoiseSVN. Denn die lokalen Pfade auf den beiden Rechnern sind jeweils SVN-Projektordner. Dass da beim Drag&Drop evtl. irgendeine ältere Version rausgekramt wird?

Eher unwahrscheinlich, das Problem ist ja, dass die Zieldatei auf dem NAS nicht überschrieben wird, und die steht ja nicht unter SVN-Verwaltung. Aber selbst wenn: SVN macht nichts automatisch. Eine alte Dateiversion wiederherstellen geht da nur manuell durch eine Update- oder Revert-Operation. (oder in speziellen Fällen durch ein Commit).

twm

[Codehunter]

Zitat von dummzeuch:

In der Regel hilft ein Neustart von Samba oder wahrscheinlich einfacher, des NAS.

Wenn das nur so einfach wäre. Das NAS wird täglich neu gestartet weil es über Nacht nicht an bleibt. Im betreffenden Fall war der Neustart noch keine 2 Stunden her. Wenn man vor jeder zu kopierenden Datei das NAS neustarten soll, dann ist man ja per USB-Stick-Turnschuh-Netzwerk noch schneller dabei.

[Bbommel]

Ich würde auch eher auf Probleme im Zusammenspiel von Windows und Samba tippen. Viele unserer Kunden haben einen Linux-Server mit Samba und dort gibt es auch immer wieder mal Probleme beim Kopieren und Überschreiben von existierenden Dateien.

TortoiseSVN greift ja eigentlich nicht direkt in das Kopieren von Dateien unter Windows ein - das sind ja alles weiterhin ganz normale Dateien. Insofern würde mich wundern, wenn das die Ursache für die Probleme wäre.

[jaenicke]

Ich habe das auch selten mal, dass Windows keine Fehlermeldung ausgibt, die Datei aber trotzdem nicht kopiert wird. Bisher konnte ich das immer mit dem Process Monitor analysieren.
Wenn es dort keinen Fehler gibt, liegt die Ursache tatsächlich eher beim Server, das war allerdings nur bei einem kleineren Teil der Fälle so.

Wir hatten das Problem bisher nur bei SMB 2 unter Linux. Mit SMB 1 gab es das Problem nicht. Warum das so ist, weiß ich nicht. Es passierte sowohl beim Zugriff von Windows als auch von Linux aus, hat also offenbar nichts mit unterschiedlichen Implementierungen zu tun.

[hoika]

Hallo,
ich hatte das Phänomen hier mit Windows 10 und lokalem kopieren.
Eine Datei in ein leeres Verzeichnis kopiert, sie war nicht zu sehen.
Erst nach F5-Drücken wurde die Datei angezeigt.

Der Spuk war mit dem nächsten Windows-Update/Eset-Nod-Update weg.

Ich würde das Kopieren mal testweise in der Kommandozeile machen (copy).

[jobo]

Also ohne weitere Angaben:
Bei einem x-beliebigen NAS würde ich mal Gnade vor Recht ergehen lassen bzw. nachschauen, was das Dashboard (oder top) schönes zum Innenleben zeigt.
Angefangen von schnellem "runterfahren" per Powerknopf oder nochbesser Steckerleistenschalter (und dann fälliger Plattensynchronisation), über schwachbrüstige CPU bis zu Applications Überfrachtung (von Dashboard, über Email bis Z wie zuviel des Guten) und Riesenbackups eines sorgfältigen Kollegen. Ein NAS kann nicht zaubern, auch wenn es Terrabyteplatten drin hat, die fürs halbe Internet reichen. Der Durchsatz ist doch meistens sehr beschränkt.

Der andere Kram wie Windows Client allgemein, neuste Performance Hacks (I want my Chache back! .. ) kommt dann noch dazu.

[TurboMagic]

Zitat von jaenicke:

Wir hatten das Problem bisher nur bei SMB 2 unter Linux. Mit SMB 1 gab es das Problem nicht.

Tja, nur gilt SMB1 heutzutage als unsicheres Einfallstor für gewisse Schädlinge und sollte daher aus dem verkehr gezogen werden,

[Codehunter]

Zitat von jobo:

Bei einem x-beliebigen NAS würde ich mal Gnade vor Recht ergehen lassen bzw. nachschauen, was das Dashboard (oder top) schönes zum Innenleben zeigt.
Angefangen von schnellem "runterfahren" per Powerknopf oder nochbesser Steckerleistenschalter (und dann fälliger Plattensynchronisation), über schwachbrüstige CPU bis zu Applications Überfrachtung (von Dashboard, über Email bis Z wie zuviel des Guten) und Riesenbackups eines sorgfältigen Kollegen. Ein NAS kann nicht zaubern, auch wenn es Terrabyteplatten drin hat, die fürs halbe Internet reichen. Der Durchsatz ist doch meistens sehr beschränkt.

Das NAS ist NAS und sonst nichts. Keinerlei zusätzliche Apps drauf. Und bei einer 30-kB-Datei sollte auch die schwächste CPU noch mithalten können. Das NAS wird ausschließlich per Netzwerk hoch- (WoL) und runter- (SSH) gefahren. Davor hängt eine Online-USV.

Habe mir die Einstellungen mal genauer angeschaut. Erstmal neuere Firmware installiert, das wurde angeboten. In den SMB-Einstellungen die v3 neu hinzu aktiviert und die verdächtig klingende Option "Asynchrones E/A" abgeschaltet.

Jetzt mal abwarten ob sich das Problem wieder zeigt oder nicht.

[Luckie]

Um was für einen NAS handelt es sich denn eigentlich?