Post by Thomas BorkPost by Michael Ebersbachxcopy "\\At\HomeLW\xxx\Dateien\ndoku" v:\ndoku /s /d /y
Gut, jetzt habe ich die genauen xcopy-Optionen zum Testen.
Post by Michael EbersbachPost by Thomas BorkPost by Michael Ebersbachanderer user aktualisert - Fehler nach 83 Dateien - wie beschrieben
Zugriff verweigert
Verzeichnis kann nicht erstellt werden -
V:\ndoku\Kapitel\Planwerte\Scan300605
Ist Scan300605 eine Datei oder ein Verzeichnis?
Ist ein Verzeichnis
Post by Thomas BorkWie sah das Datum der Datei und aller übergeordneten Verzeichnisse aus?
Blöd - den eisfair-Testserver habe ich inzwischen wieder plattgemacht.
Die Ausgangsdaten liegen noch auf \\at\tmp , ein W23SP1-Server:
Alle Ordner haben 16.9.2005, 21:03 als Datum, weil es nur eine Kopie der
eigentlichen Ausgangsdaten ist, also alle Ordner zurselben Zeit erstellt
wurden. Die innenliegenden Files sind also alle älter, ältestes File aus dem
Jahr 2001. Bei meiner Durchsicht konnte ich kein System herausfinden - alle
Dateien haben das Attribut "A" gesetzt, ein System nach Dateitypen oder
Alter war nicht erkennbar warum eben kopiert oder nicht.
Und vor die Birne klatsch - die ganzen xcopy und robocopy-Protokolle lagen
auf der samba-share.
Nichts desto trotz - es ist meiner Ansicht nach mit
------ jeder ------
gewachsenen Ordnerstruktur reproduzierbar. Nimm einfach eine solche (wie
eigene Dateien o.Ä.) und probier es selbst.
--> gerade mit windows\system32 getestet - auf jedem Windows Rechner
vorhanden:
xcopy c:\windows\system32 \\sv\public\system32 /s /e /d /y
(bitte Ordner vorher anlegen oder xcopy-Option setzen oder v eingeben -
damit xcopy das Ziel als Ordner erkennt)
1. auch hier kopiert xcopy einige Dateien im 2. Lauf erneut, bis es zu 2.
kommt
2. xcopy bricht hier schon reproduzierbar im 1. (!) Lauf ab mit:
Verzeichnis kann nicht erstellt werden -
\\sv\public\system32\appmgmt\MACHINE
interessant finde ich dabei die Stelle des Absturzes/Fehlers:
xcopy will offensichtlich eine Datei in den Unterordner MACHINE kopieren. Es
existiert in dieser Situation weder der Unterordner MACHINE noch der
Unterordner appmgmt. appmgmt wird noch angelegt - MACHINE nicht mehr.
Ich erinnere daran, dass ich an anderer Stelle schrieb, das der Abbruch
unter ähnlichen Umständen erfolgte. Da wollte xcopy eine Datei
aktualisieren, die nicht im dem ordner lag, für den die Zugriffsrechte
fehlten, sondern in einem Unterordner dieses Ordners!
Ist es möglich, dass hier ein Problem bei der Adressierung vorliegt, besser
gesagt, bei der Art, wie eine Datei oder ein Ordner angesprochen wird?
Post by Thomas BorkPost by Michael EbersbachPost by Thomas BorkPost by Michael Ebersbachoriginal-User versucht nun die Aktualisierung - auch Abbruch an
derselben Stelle!!!!
was ist da nur passiert???
Wenn ich das nur wüsste :)
Eventuell kommt auch ein Gross- Kleinschreibungsproblem in Frage oder
Name-Mangling.
? keine Ahnung, was das ist.
Post by Thomas BorkPost by Michael EbersbachPost by Thomas BorkEin W2K Server hat 2 Laufwerke gemappt, eins mit einem Samba-Share, eins
mit einem Novellshare?
richtig! Der Test erfolgte allerdings jetzt mit einem Netzlaufwerk auf
W23, Mittelsmann ein XP-Rechner
Grrr, was heisst "Mittelsmann ein XP-Rechner"?
Bitte ein genaues Bild mit ASCII-Art a la
Novell --- X: auf W23 --- Y: auf W23 --- Sambashare
| |
| |
---- xcopy ---
Mittelsmann heisst hier, der XP-Rechner hat Quelle und Ziel gemappt und auf
ihm läuft das xcopy ... das ist aber nicht das Problem. Liegen Die
Ausgangsdaten lokal 8also auf dem XP oder W2k blabla) ist das Verhalten
identisch.
Post by Thomas BorkPost by Michael EbersbachPost by Thomas BorkPost by Michael Ebersbachanderer user aktualisiert - auch hier - ohne dass eine Änderung erfolgte
werden 127 Dateien aktualisiert --> aber kein Fehler!!!
ob es vielleicht ein Zeichensatz oder Datentransferproblem gibt?
durch xcopy ... /d ... dürften ja nur veränderte Dateien kopiert werden.
Aber es wurden keine verändert!!
Aber xcopy ist der Meinung, sie wurden verändert. Wir müssen
herausbekommen, warum xcopy dieser Meinung ist.
Post by Michael Ebersbachrobocopy \\at\tmp\ndoku z:\ndoku /xo /e /z /r:2
Was soll /r:2 bewirken?
/R:2 bewirkt Abbruch nach 2 erfolglosen Versuchen. Standard ist hier 1
Million, das war mir zu viel.
Post by Thomas BorkPost by Michael Ebersbach4 \\at\tmp\ndoku\
Newer 27648 Aktuelles.doc 0% 100%
Newer 61440 Arbeitszeit.xls 0% 100%
0 \\at\tmp\ndoku\Kapitel\
2005/09/16 21:29:33 ERROR 5 (0x00000005) Changing File Attributes
\\at\tmp\ndoku\Kapitel\
Zugriff verweigert
es wurden also zwei Files in der Wurzel des Verzeichnisses aktualisert
(die eigentlich nicht zu aktualisieren waren, weil nicht neuer) und dann
erfolgt der Abbruch mit der Meldung Zugriff verweigert für die Attribute
eines Ordners!!!
Auch hier sind wieder das Datum und Rechte des Ordners Kapitel und aller
übergeordneten Verzeichnisse gefragt.
wie oft denn noch ? Auf Ziel Vollzugriff für users, jeder und den Nutzer,
der die Ordenrstruktur erstmalig anlegte, auf Quelle mindestens Leserechte,
mit Vollzugriff ist das Verhalten identisch.
Post by Thomas BorkPost by Michael EbersbachIm übrigen würde robocopy laut dem erfolgreichen vorhergehenden Logs
nicht etwa eine Datei im Ordner Kapitel ändern, sondern eine Datei, die
in einem weiteren Unterordner liegt.
War das wieder Scan300605?
nein. Robocopy ist im Gegensatz zu xcopy nicht so veranlagt, beim ersten
Mißerfolg alles hinzuschmeissen. Es bricht für das aktuelle File nach
/R:anzahl von versuchen ab und nimmt dann das nächste File.
Die Reihenfolge der Abarbeitung ist durchaus verschieden. bei xcopy habe ich
es sogar erlebt, dass es die Reihenfolge bei identischer Quelle verändert.
Nicht ganz willkührlich - aber so halb.
Dazu paßt auch, dass bei meinen versuchen die Anzahl der erneut kopierten
Dateien zwischen xcopy und robocopy nicht identisch war. Innerhalb der Tools
jedoch schon - also reproduzierbar bezogen auf das Tool.
Post by Thomas BorkEventuell würde robocopy in diesem Zusammenhang versuchen, die Attribute
von Kapitel zu ändern (mtime).
Davon Rede ich schon immer!
Post by Thomas BorkPost by Michael EbersbachEs werden auch hier ohne Aktualisierung der Ausgangsdaten Files
wiederholt kopiert. Der Wechsel zum anderen Nutzer führt wieder zum
Abbruch wegen Zugriff auf Attribute verweigert.
1.
Sowohl xcopy als auch robocopy sind der Meinung, die Daten haben sich
geändert. Wenn die beiden Programme das an irgendeiner Eigenschaft der
Dateien festmachen (das muss so sein), dann _muss_ das auch zu ermitteln
sein.
2.
Eventuell hilft es uns weiter, wenn wir herausbekommen, welche Attribute
geändert werden sollen.
Post by Michael EbersbachIn Windows-Share ist Vollzugriff immer auch Zugriff auf die Attribute -
in Samba nicht - dort bleibt dieses Recht für root(?).
Unter Unix bleibt dieses Recht root und dem Eigentümer der Datei
vorbehalten. Samba gestattet dieses Recht mit 'dos filemode = yes'. Wenn
das nicht sauber funktioniert, ist das ein Fehler der beseitigt werden muss.
dos filemode = yes habe ich diesmal nicht nochmal getestet
Post by Thomas BorkPost by Michael EbersbachJedenfalls lehnt SAMBA jeden Schreibzugriff auf Attribute ab - sogar
gegenüber dem Ersteller/Besitzer!
Kannst Du "ungefährliche" Testdaten bereitstellen, mit denen sich das
nachvollziehen lässt?
Schwerlich; wie schon beschrieben ist der Fehler bei mir leicht
reproduzierbar. Bitte Versuch es doch mal mit irgendeiner Deiner
Ordnerstrukturen.
Leider kann ich mich mit dem Problem nicht ewig aufhalten. Innerbetrieblich
haben wir eine Lösung gefunden und für meinen privaten eisfair-Server ist
die Problematik nicht relevant.
Allerdings halte ich das Problem eben für ein Grundsätzliches.
Wenn mir eine SAMBA-Share eine SMB-Share simulieren soll, tut sie das eben
nur, wenn sie sich tatsächlich identisch verhält.
Das Arbeiten mit Rechten gehört hier unmittelbar dazu. Es ist logisch, dass
es irgendwann Probleme gibt, wenn SAMBA-Vollzugriff nicht gleich
SMB-Vollzugriff ist (egal welcher filemode).
Die Unterschiede sind schon auf dem Sicherheitsreiter von Windows zu
erkennen (kein Ersteller-Besitzer, keine Vererbung). Und spätestens wenn auf
der Sicherheitstab Einstellungen vorgenommen werden, scheitert dies.
Da ich aber Realist bin, denke ich sicher zu wissen, dass das Interesse, an
einer echten Windows-Implementation von SAMBA begrenzt ist. Insbesondere
auch deshalb, weil die Windows-Rechteimplementation zum einen sicher nicht
trivial ist und zum anderen völlig gegen das Unix-Konzept verstößt.
Mischa