C O P Y R A   5 . 0
Home | Einstellungen | Profile | Batch | Zeitpläne | Formeln | Strategien | Bestellen
 
 
FAQ - Probleme und Sonderfälle

Datei-/Ordnernamen enden manchmal mit dem Zeichen # und einer 5-stelligen Hex-Zahl
Im Zielordner befinden sich Dateien mit dem Namen $$TestFile$$
Fehlermeldung beim Speichern von Profilen, Batchdateien usw.
Das Dateidatum von Original und Kopie weicht manchmal um 1 Sekunde voneinander ab
Probleme mit Dateien größer als 2 Gigabyte
Datei passt trotz genügend Speicherplatz nicht auf den Zieldatenträger
Warum prüft COPYRA vor Kopierbeginn nicht, ob genügend Speicher im Ziel frei ist?
Warum hat COPYRA keine Fortschrittsanzeige?
Probleme mit Dateinamen beim Datenaustausch zwischen unterschiedlichen Systemen
Zwei gleichnamige Dateien sind im selben Ordner aufgetaucht
Probleme mit gleichnamigen Volumes
Probleme mit Firewire-Laufwerken
Sommerzeit-Umstellung: COPYRA kopiert auch nicht geänderte Dateien

 
  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

  • der Datei- oder Ordnername länger als 31 Zeichen ist und
  • auf dem Zielrechner MacOS bis Version 9 oder MacOS X 10.3.6 läuft oder
  • auf dem Zielrechner Windows oder Linux läuft und dieser über das MacOS-Netzwerkprotokoll AFP verbunden ist
Der Grund ist, dass MacOS bis Version 9 keine Dateinamen länger als 31 Zeichen speichern kann. Die Namenskürzung erfolgt also aus Kompatibilitätsgründen, auch wenn der Zielrechner lange Namen problemlos speichern könnte. Nach einer Änderung am AFP-Protokoll in MacOS 10.3.6 tritt dieses Problem wieder häufiger auf, insbesondere auch im "Finder".

Wichtig: Wenn Sie MacOS 10.3.6 benutzen, installieren Sie unbedingt das Update MacOS 10.3.7 bzw. eine höhere Version!

 
  Im Zielordner befinden sich Dateien mit dem Namen $$TestFile$$

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:

  1. auf Ihrem Computer im Hintergrund ein Antiviren-Programm läuft, welches neu erstellte Dateien sofort öffnet und auf Viren untersucht. Dabei wird die betreffende Datei gesperrt, sodass COPYRA sie nicht mehr löschen kann.
     
  2. unter Linux/UNIX die Rechte zum Lesen des Inhaltsverzeichnisses nicht gesetzt sind. Das Verhalten von COPYRA ist hier also genaugenommen korrekt. Das Problem kann nur gelöst werden, indem die Rechte für das Auslesen des Inhaltsverzeichnisses gesetzt werden.
     
  3. COPYRA auf einem MacOS-9-Rechner mit AppleShare IP (ASIP) läuft. Hierfür existiert derzeit kein Lösungweg, sodass diese Konstellation nicht empfohlen wird.
Finden und löschen Sie die $$TestFile$$-Dateien am besten mit der Waisensuchfunktion von COPYRA.

 
  Fehlermeldung beim Speichern von Profilen, Batchdateien usw.

Beobachtet wurden bisher sporadisch die Fehlermeldungen "Keine Schreibrechte" und "Unbekannter Fehler". Die Ursachen hierfür sind dieselben wie im vorhergehenden Abschnitt.

 
  Das Dateidatum von Original und Kopie weicht manchmal um 1 Sekunde voneinander ab

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.

 
  Probleme mit Dateien größer als 2 Gigabyte

Dieses Problem hat mehrere Ursachen und ist derzeit nicht vollständig lösbar.

  • Windows:
    • Dateisystem NTFS: keine Probleme
    • Dateisystem FAT: Kopiervorgang dauert extrem lange oder bleibt stehen
       
  • Linux: bisher keine Probleme feststellbar
  • MacOS X: Datei wird vom Finder kopiert
  • MacOS 9: Kopieren nicht möglich

 
  Datei passt trotz genügend Speicherplatz nicht auf den Zieldatenträger

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.

 
  Warum prüft COPYRA vor Kopierbeginn nicht, ob genügend Speicher im Ziel frei ist?

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.

 
  Warum hat COPYRA keine Fortschrittsanzeige?

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.

 
  Probleme mit Dateinamen beim Datenaustausch zwischen unterschiedlichen Systemen

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.

 
  Zwei gleichnamige Dateien sind im selben Ordner aufgetaucht

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.

 
  Probleme mit gleichnamigen Volumes

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.ä.).

 
  Probleme mit Firewire-Laufwerken

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.

 
  Sommerzeit-Umstellung: COPYRA kopiert auch nicht geänderte Dateien

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