Fehlverhalten beim Verzeichnisse synchronisieren

[La Laucha]

Hallo,

wenn beim Verzeichnisse synchronisieren eine Datei z.B. noch in Benutzung ist, dann frage TC nach "Überspringen" oder "Abbrechen". Abgesehen davon, dass es wünschenswert wäre hier noch ein Button "Wiederholen" zu haben ist es m.E. absoult nicht akzeptabel, dass TC die Daten auf dem Zieldatenträger in diesem Moment bereits gelöscht hat.
Schön wäre es ausserdem, wenn TC nach erfolgter Synchronisation optional nicht nochmal die Verzeichnisse vergleichen würde. Bei 80 GB dauert dies unnötig lange.

[Cineatic]

...
Schön wäre es ausserdem, wenn TC nach erfolgter Synchronisation optional nicht nochmal die Verzeichnisse vergleichen würde. Bei 80 GB dauert dies unnötig lange.

Hallo!

Dies lässt sich problemlos mittels ESC-Taste abbrechen. Die nachträgliche Kontrolle, ob die Verzeichnisse nun wirklich exakt übereinstimmen, ist also kein Muss.

[sqa_wizard]

dass TC die Daten auf dem Zieldatenträger in diesem Moment bereits gelöscht hat.

Gelöscht werden die Dateien nur im Asynchron-Modus. Dabei auch nur die Dateien gelöscht, die im Quellverzeichnis gar nicht vorhanden sind.
Dateien die überschrieben werden sollen, werden kopiert und anschliessend gelöscht.

[La Laucha]

Negativ. Ich rede auch nicht vom Asynchronem Modus.
Konkret handelt es sich um die outlook.pst. Auf meinem Backupserver war sie vorhanden und nachdem ich synchronisiert hatte und diese Datei wegen "in Benutzung" nicht kopiert werden konnte, war sie auf dem Server gelöscht. Somit scheint TC das File "live" zu überschreiben und nicht erst temporär anzulegen. Das verhalten kenne ich von anderen Programmen auch, aber gibt es da keine anderen Lösungsansätze??
Zumindest ist an dieser Stelle spätestens ein log File erforderlich, um solche Vorgänge nachvollziehen zu können.

[La Laucha]

Herr Gisler, ist dies das reguläre Vorgehen des TC ? Es müsste eigentlich für alle reproduzierbar sein.

[norfie]

[ghisler(Author)]

Nein, damit hat das NICHTS zu tun. TC versucht erst die Quelldatei zu öffnen, falls das geht, öffnet er die Zieldatei und schreibt die Daten. Pech hat man, wenn nicht die ganze Datei gesperrt ist, sondern nur Teile davon, z.B. bei einer Datenbank, weil da das Kopieren erst beim eigentlichen Lesen aus der Datei fehlschlägt. TC müsste erst mal die gesamte Datei in den Speicher lesen, um sicher zu gehen, dass sie komplett lesbar ist.

Es gibt viele Gründe, wieso TC eine bestehende Datei öffnet und überschreibt, statt eine temporäre Datei anzulegen. Die wichtigsten: Die Datei kann dateisystemabhängige Streams, Permissions und Attribute haben, die bei einem Neuanlegen natürlich fehlen würden. Beispiele sind Netware-Attribute und -Trustees oder NTFS-Benutzerrechte.

[La Laucha]

Nun frag ich mich nur, ob das PST File von Outlook eine Datenbank in diesem Sinne ist !? Für mich scheint sie augenscheinlich KOMPLETT gesperrt zu sein, allerdings weiss ich wie ich es definitiv herausfinden könnte. Ich kann mich also täuschen.

[ghisler(Author)]

Ja, das PST-File ist eine Datenbank, Outlook scheint sogenanntes Record-Locking zu verwenden, also nur einzelne Mails exklusiv zu sperren.

[La Laucha]

Okay, das ist nachvollziehbar.
Können Sie jedoch eine Aussage dazu treffen, ob ein Log geplant ist bzw. wann es umgesetzt werden wird ?!
Ähnliches gilt für den Kopierdialog wenn man z.B. "alle überspringen" auswählt - hier benötige ich einfach nach stundenlangen kopieraktionen eine Übersicht über die nicht gelaufenen Vorgänge.

Großes Lob an Sie, dass Sie sich noch immer aktiv hier beteiligen. Das hilft sehr !!!