Befehl "cp --preserve" auf SMB Freigabe behält Erstelldatum der Datei nicht

[Hometux]

Interessanterweise wenn man eine ganze Hand voll Dateien in einer Schleife auf ein SMB Share kopiert dann ist es eher zufällig, denn einige der Dateien behalten den originalen Zeitstempel und andere wiederum nicht.

Guten Abend zusammen, TL;DR

genau so ein Problem ärgert mich seit einiger Zeit unter macOS Ventura (aktuell 13.4.1). Ich kann es nicht mehr genau nachvollziehen, ob es durch ein bestimmtes 13.x Update kam oder möglicherweise durch ein Synology Update.

Allerdings habe ich es nicht bei cp -p (weil ich das i.d.R. nicht benutze) sondern beim Kopieren via Commander One Pro (aktuelle App Store Version 3.5.2 3667) und Beyond Compare 4.4.6 (Build 27483) Standard Edition (aber auch schon mit einigen Vorversionen).

Dieser Effekt ist bei Beyond Compare besonders ärgerlich, da dieses Vergleichstool u.a. dazu gedacht ist umfangreiche Dateibäume an mehreren verschiedenen Stellen manuell abzugleichen. Z.B. Desktop Mac <-> Diskstation <-> MacBook. Je nachdem wo ich gerade arbeite, kommen neue Dateien hinzu, vorhandene werden geändert, verschoben oder gelöscht.

Im Prinzip tritt das Problem aber auch schon mit einem Mac + DS (SMB mount) bei einem simplen Beispiel auf.
Neues Musik Album mit 10 Tracks in iTunes gekauft und heruntergeladen.
Am nächsten Tag werden beim Sync-Lauf diese neuen 10 Dateien (mit Zeitstempel von gestern) als nur links (Mac) vorhanden erkannt und nach rechts (DS) synchronisiert.
Seit einiger Zeit bekommen diese Dateien auf Seite DS durch die Kopie den Zeitstempel vom Zeitpunkt des Sync.
Beim nächsten Abgleich ist Beyond Compare nun natürlich der Meinung, dass diese 10 Dateien (welche eigentlich ja gar nicht verändert wurden bzw. werden sollten) nun auf der rechten Seite aktueller wären und schlägt diese zum erneuten Synchronisieren nun in die andere Richtung zurück auf den Mac vor.

Das ist super ätzend, mal ganz abgesehen davon, dass man so den original Zeitstempel verliert (bei digitalisierter Musik vielleicht nicht so wichtig, bei jeder anderen Art von selbst erzeugten Dokumenten hingegen schon, wenn man nicht mehr erkennen kann, welche Kopie denn den letzten tatsächlichen Überarbeitungsstand hat.). Wenn man zudem z.B. versionierte Backups oder Rsync einsetzt (Time Machine oder Hyper Backup), werden durch dieses verfummeln der Zeitstempel durch hin und her synchronisieren ja immer wieder die gleichen Dateien gesichert, deren Inhalt sich meist ja gar nicht geändert hat und nur aufgrund des Zeitstempel für neu gehalten werden.

Wie auch beim TO tritt dieser Effekt dabei aber nicht immer bei allen neuen kopierten Dateien auf, es scheint ein Zufallsprodukt zu sein.
Vor allem passiert dies bei den selben Dateien NICHT, wenn man dieser per Finder vom Mac auf die DS kopiert, dann ist im Anschluß auch Beyond Compare zufrieden, da die Dateien auf beiden Seiten vorhanden sind und der Zeitstempel jeweils einheitlich ist.

Ich nutze diesen Sync schon seit Jahren, mit verschiedenen älteren App, Mac und DSM Versionen und es war das nie ein Problem, aber seit einigen Monaten ist der Wurm drin.

Da ich nicht mal sagen kann, ob macOS, DSM oder die Apps die Wurzel des Übels sind, habe ich bisher nirgends ein Ticket auf gemacht.
Wenn ich allerdings hier quer lese, (dass es auch mit anderen OS und auf der Kommandozeile auftritt) denke ich eher DSM oder die Samba Settings die Ursache sein müssen?

Wenn dafür jemand die Lösung findet, gebe ich einen aus.

 

[luddi]

Danke für deine Erfahrungen hierzu.

Bei mir kommt auf MacOS als Dateibrowser entweder Finder oder Forklift zum Einsatz. Beide verhalten sich bei Kopiervorgängen auf ein SMB Share korrekt und verändern hierbei nicht den Zeitstempel von Modify der Datei.

Auch ich verwende sehr häufig Beyond Compare aber hier habe ich die Erfahrung noch nicht gemacht weil ich Vergleiche ausschließlich binär oder CRC basiert durchführe. Aber ich gebe mal in der nächsten Zeit besonders darauf acht.

Bezüglich root cause habe ich selbst auch keine Idee. Ich möchte nochmals explizit darauf hinweisen, dass dies kein DSM spezifisches Problem ist. Das gleiche Verhalten habe ich auch festgestellt wenn der SMB Server ein anderes Device mit z.B. einer anderweitigen Linux Distribution ist.
Also bitte die Grafik in dem Beitrag #11 auf der Seite des SMB-Server nur als ein Beispiel mit Synology DSM zu betrachten. Ich selbst habe diese Tests auch auf einem Ubuntu als SMB-Server durchgeführt mit dem gleichen Ergebnis.

Hier sehe ich nicht DSM als root cause sondern ich, verdächtige hier entweder SMB oder cp.
Etwas anderes ergibt jedenfalls mit der aktuellen Erkenntnis keine logischen Schlüsse.

 

[Hagen2000]

In einigen Fachforen finden sich zahlreiche Themen zu dem Problem, dass nicht-leere Dateien einen falschen Zeitstempel erhalten. Ich werde am Ende dieses Beitrags einige kommentarlos verlinken.

Grundsätzlich scheint der Befehl cp mit zwei "Handles" zu arbeiten, einen für die Datenübertragung und einen für das Einstellen der Attribute. Werden nun Daten übertragen (d. h. die Datei ist nicht leer), erfolgt offensichtlich das Schließen (und somit das Schreiben der letzten Daten) des Datenstroms nach dem Setzen der Attribute und somit wird der bereits gesetzte Zeitstempel wieder überschrieben.
Hört sich erstmal nach einem Fehler des cp-Befehls an und erklärt auch, dass der Fehler auch bei einem Mount mit APFS auftritt.

Andererseits wurden angeblich Kernel-Patches vorgenommen, die das Problem umgehen sollen. Leider konnte ich auf die Schnelle nicht ermitteln, ob dies den Kernel des SMB-Clients oder des SMB-Servers (also z.B. eines Synology-NAS) betrifft.

Bei meinen Tests in #20 habe ich festgestellt, dass mit CentOS 6.10 der Fehler nicht auftritt. Grund ist offenbar, dass dieses alte Betriebssystem nur SMB V1.0 unterstützt und das ist auch ein möglicher Workaround: Die Benutzung des (abgekündigten) SMB-Protokolls V1.0. Damit funktioniert das Kopieren nicht-leerer Dateien mit Option -p wieder korrekt.
Ansonsten wird von neueren Betriebssystemen das SMB-Protokoll V3.1.1 verwendet.
Darüber hinaus musste ich bei meinen Tests feststellen, dass auch Dateiattribute nicht korrekt abgebildet wurden (konkret das "Read-Only"-/Schreibschutz-Attribut). Auch dieses Problem tritt mit SMB V1.0 nicht auf.

Alles Geschriebene ohne Gewähr auf Vollständigkeit und Korrektheit

https://bugzilla.kernel.org/show_bug.cgi?id=198967
https://lists.samba.org/archive/samba-technical/2019-January/132132.html
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2007055
https://access.redhat.com/solutions/3801851

 

[Hagen2000]

Nachträge:

• Zeitstempel: Bei Verwendung von AlmaLinux 9.1 mit Kernel 5.14 wird der Zeitstempel korrekt gesetzt. Somit gilt der zuvor erwähnte Kernel-Patch also für den SMB-Client und setzt auf diesem einen entsprechend neuen Kernel voraus.
• Dateiattribute: Die Unix Extensions für Samba gibt es offenbar nur für SMB V1.0. Für SMB V3.1.1 sollten diese durch Posix-Erweiterungen abgelöst werden, aber der Implementierungsstatus ist unklar.