| C O P Y R A 5 . 0 | |
|
|
|
FAQ - Probleme und Sonderfälle
Datei-/Ordnernamen enden manchmal mit dem Zeichen # und einer 5-stelligen Hex-Zahl Dies passiert nur, wenn der Quellrechner ein MacOS-X-Rechner ist und
Wichtig: Wenn Sie MacOS 10.3.6 benutzen, installieren Sie unbedingt das Update MacOS 10.3.7 bzw. eine höhere Version! Diese Dateien erzeugt COPYRA, um zu prüfen, ob für die betreffenden Ordner die zum Kopieren notwendigen Schreibrechte gesetzt sind, und löscht sie unmittelbar danach wieder. Der Anwender bekommt davon normalerweise nichts mit. Das abschließende Löschen schlägt jedoch fehl, wenn:
Beobachtet wurden bisher sporadisch die Fehlermeldungen "Keine Schreibrechte" und "Unbekannter Fehler". Die Ursachen hierfür sind dieselben wie im vorhergehenden Abschnitt. Dies kann passieren, wenn Dateien von MacOS X über das SMB-Protokoll zu einem Windows- oder Linux-PC kopiert werden. Da das FAT-Dateisystem keine ungeraden Sekundenwerte im Dateidatum speichern kann, rundet die SMB-Protokollengine ungerade Sekundenwerte vorsichtshalber immer auf den nächstniedrigen geraden Wert ab (obwohl das beim heute üblichen NTFS-Dateisystem gar nicht nötig wäre). Dadurch sind viele Kopien eine Sekunde älter als die Originaldatei. Wird ein Backup-Profil mit der Einstellung "nur aktuellere oder noch nicht existierende Dateien kopieren" eingerichtet, würden die betroffenen Dateien bei jedem Backup immer wieder kopiert werden, obwohl sie gar nicht geändert wurden. COPYRA kann nicht erkennen, wie eine solche Sekundenabweichung zustande gekommen ist. Daher geht COPYRA generell davon aus, dass eine Datei, die lediglich eine Sekunde älter als das Original ist, nicht veraltet ist und folglich nicht aktualisiert zu werden braucht. Dieses Problem hat mehrere Ursachen und ist derzeit nicht vollständig lösbar.
Die geschieht immer dann, wenn die zu kopierende Datei auf dem Zieldatenträger bereits existiert und größer ist als der noch freie Speicher auf dem Zieldatenträger. Da COPYRA die zu überschreibende (alte) Zieldatei erst löscht, wenn die neue Datei korrekt im Ziel angekommen ist, müssen alte und neue Datei für einen Moment gleichzeitig auf den Zieldatenträger passen. Dies dürfte nur auf sehr kleinen Datenträgern zum Problem werden, z.B. auf Disketten. Da aber gerade Disketten dazu neigen, mitten in einem Kopiervorgang einfach kaputt zu gehen, ist es besonders wichtig, dass COPYRA hier nicht voreilig die zwar nicht ganz aktuelle, aber wenigstens intakte Zieldatei löscht. Dieses Problem kann also nur manuell gelöst werden: entweder Sie kopieren die Datei manuell oder löschen zuvor deren Kopie auf dem Zieldatenträger. Die Größe des freien Speichers, wie sie im Laufwerks-Informationsfenster angezeigt wird, ist für COPYRA nutzlos, da beim Kopieren ja nicht nur Dateien hinzugefügt werden, sondern auch bereits vorhandene ersetzt werden - wieder andere Dateien werden überhaupt nicht kopiert. Um den tatsächlichen Speicherverbrauch berechnen zu können, müsste COPYRA den Kopiervorgang vor dessen Ausführung einmal komplett simulieren. Dies dauert insbesondere bei Aktualisierungsbackups fast genau so lange wie der Kopiervorgang selbst - die Laufzeit von Profilen würde sich also fast verdoppeln. Da zu wenig Speicherplatz eher ein Ausnahmefall ist, würde ein Großteil dieser Simulationen völlig umsonst laufen und nur unnütz Zeit kosten. Für den Betrieb einer Fortschrittsanzeige benötigt ein Programm die insgesamt zu kopierende Datenmenge als 100%-Wert. Dazu müsste vor Kopierbeginn der gesamte Quellordner mit allen Unterordnerzweigen durchkämmt werden, um die Größen der zu kopierenden Dateien zu addieren. Dies dauert insbesondere bei Aktualisierungsbackups fast genau so lange wie der Kopiervorgang selbst - die Laufzeit von Profilen würde sich also fast verdoppeln. Alle aktuellen Betriebssysteme speichern Dateinamen im Unicode-Format, sodass Umlaute, ß usw. in der Regel keine Probleme mehr bereiten. In einigen Konstellationen kann es jedoch vorkommen, dass Umlaute im Dateimanager des Zielrechners falsch dargestellt werden, während sie im Dateimanager des Quellrechners korrekt angezeigt werden. Solange der Zielrechner lediglich als Server eingesetzt wird, sollte das kein Problem sein - Sie können dies prüfen, indem Sie die Option "verwaiste (nur im Ziel existierende) Dateien und Ordner auflisten" einschalten: im Normalfall sollte COPYRA dann keine Dateien anzeigen. Unter Windows sind die Zeichen :/*\?"<>|~ und führende/anhängende Leerzeichen sowie die reservierten Gerätenamen CON, AUX, PRN, NUL, COM1, COM2 ... COM9, LPT1, LPT2, LPT3 sowie CLOCK$ nicht erlaubt (auch nicht mit angehängter Datei-Endung, wie z.B. nul.gif). Ältere Mac-Server verwenden gegenüber Windows-PC manchmal sogar die strengeren DOS-Regeln, die z.B. alle ASCII-Zeichen < 32 sowie das Plus-Zeichen, eckige Klammern, Kommata, Semikola u.a. verbieten. Dateien mit ungültigen Namen können grundsätzlich nicht kopiert werden. Sie müssen diese Dateien zuvor umbenennen. Das Folgende ist bislang nur unter MacOS 8 beobachtet worden. Dieses Phänomen tritt auf, wenn COPYRA eine Programmdatei kopieren soll, diese Programmdatei im Ziel bereits existiert und das Programm läuft. MacOS verhindert jedoch das Überschreiben eines laufenden Programmes, lässt das Kopieren der neueren Programmdatei jedoch zu, sodass diese dann scheinbar zweimal im selben Ordner existiert (scheinbar deswegen, weil - im Finder unsichtbar - das System an den Namen der alten Programmdatei das ASCII-Zeichen 13 angehängt hat). Bei eingeschalteter Option "verwaiste (nur im Ziel existierende) Dateien und Ordner auflisten" wird die "überzählige" Programm-Datei dann auch "korrekt" aufgelistet und kann sogar gelöscht werden - gelöscht wird dann allerdings die gerade kopierte Version des Programmes! Achten Sie also darauf, dass im Zielordner keine Anwendung läuft, die Sie ersetzen wollen. Dieser Effekt tritt anscheinend nur auf, wenn Quell- und Zielordner beide auf der lokalen Festplatte liegen - nicht jedoch, wenn der Zielordner auf einem anderen Computer (Netzwerk) liegt. Den letzteren Fall erkennt COPYRA diesen Fehler und stellt die alte (gerade laufende) Programmversion wieder her. Sie müssen dann das Programm schließen und den Kopiervorgang wiederholen. Diese Situation kann auch mit ganz normalen Daten-Dateien eintreten, wenn diese offen und von ihrer Anwendung "gelockt" worden sind. Das Folgende betrifft nur MacOS Verweisen Quell- und Zielpfad auf zwei unterschiedliche, jedoch exakt gleichnamige Volumes, kann COPYRA nicht sicher feststellen, ob die beiden Pfade tatsächlich auf zwei unterschiedliche oder doch auf ein und dasselbe Volume verweisen. COPYRA geht dann vom zweiten Fall aus und meldet den Fehler "Ineinanderkopieren eines Ordners (zyklische Kopie) nicht erlaubt". Eine generelle Lösung für dieses Problem gibt es nicht - ist eines der beiden gleichnamigen Volumes ein Wechselmedium (Diskette, ZIP), sollten Sie dessen Namen manuell ändern (z.B. durch Anhängen einer Ziffer o.ä.). Das Folgende ist bislang nur unter MacOS beobachtet worden. Beim Kopieren auf Firewire-Festplatten kann es manchmal zum Abbruch eines Kopiervorganges kommen. Die genaue Ursache ist unbekannt, es handelt sich vermutlich um Hardwareprobleme, die in letzer Zeit jedoch seltener geworden sind. Ein Fall konnte jedoch reproduziert werden: Wurde die FireWire-Platte mit einem eigenen Netzteil betrieben, kam es nach etwa einer Minute zu einer Umschaltung auf die Stromversorgung im FireWire-Kabel, d.h., die Platte wurde "ausgeworfen" und etwas später wieder gemountet. Nach Demontage des Netzteiles ist dieses Problem nicht wieder aufgetreten. Dieses Phänomen ist bisher nur unter MacOS bis Version 9 beobachtet worden, könnte aber theoretisch auch unter anderen Systemen auftreten Wenn die Option "nur aktuellere oder noch nicht existierende Dateien kopieren" aktiviert ist, kann es nach der Umstellung zwischen Sommerzeit und Normalzeit ("Winterzeit") dazu kommen, dass COPYRA sämtliche (!) Dateien kopiert. Die Ursache ist, dass MacOS 9 bei der Zeitumstellung das Dateidatum aller Dateien um eine Stunde vor- bzw. zurückstellt, wenn die Zeitumstellung durch Setzen/Entfernen des Sommerzeit-Häkchens im Kontrollfeld "Datum & Uhrzeit" vorgenommen wird. Wird die Umstellung auf einem anderen Rechner stattdessen durch Verstellen der Systemzeit realisiert, kommt es im Netzwerk zu Inkonsistenzen zwischen den Rechnern. Selbst wenn diese Umstellung einheitlich durchgeführt wurde, ist dieses Problem schon aufgetreten. Hinzukommt, dass Wechseldatenträger zur Zeitumstellung nicht vom System erreichbar sind, also zunächst nicht umgestellt werden. Diesem Problem ist mit Logik anscheinend auch nicht beizukommen - am schnellsten werden Sie es los, indem Sie hintereinander weg alle Backups ausführen, sobald das Phänomen das erste Mal auftritt. home | sitemap | Zur Copyra-Homepage | top |