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

[luddi]

Wer schon häufig mit der Kommandozeile oder bzw. mit bash Scripten gearbeitet hat, dem ist evtl. auch aufgefallen, dass bei einem copy Befehl cp mit der Option --preserve die Timestamps (Erstelldatum) der Datei nicht zwangsläufig beibehalten werden.
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.
Und dabei spielt es keine Rolle, ob man einen SMB Share auf Synology oder auf einer anderen Linux Distro verwendet. Ich habe hier schon versucht alles Mögliche auszuschließen.
Jedoch wenn man die gleichen Dateien via Datei Explorer (ganz egal ob Windows, Linux oder Mac) wie Explorer, Dolphin, Nemo, Finder und wie sie alle heißen auf den gleichen Share kopiert so behalten sie auch brav ihren Zeitstempel der Dateierstellung.

Somit scheint es wohl vermutlich eher am cp Befehl in Zusammenhang mit SMB zu liegen.
Vielleicht hat sonst noch jemand gleiche oder ähnliche Beobachtungen gemacht und würde auch gerne seine Erfahrungen teilen.

 

[Benares]

Kannst du mir bitte mal ein Beispiel nennen? Ich habe eben ein paar Files mit "cp --preserve file1 file2" kopiert, da blieb alles erhalten.

 

[luddi]

Hi @Benares, klar kann ich das machen.

Ich muss mich allerdings an einer Stelle korrigieren, weil ich mich lange nicht mit dem Thema beschäftigt hatte.
Es ging um das Modify Date und nicht um das Create Date.

Hier sieht man folgenden Ablauf anhand einer bestehenden jpeg Datei.

1. Kopiere jpeg Datei mit cp -p (Äquivalent für --preserve)
2. Liste den Inhalt des Zielverzeichnis -> Ergebnis: Zeitstempel geändert
3. Erstelle leere Datei "file1" via touch
4. Warte etwas und prüfe die aktuelle Zeit mit date
5. Kopiere dummy Datei "file1" mit cp -p -> Ergebnis: Zeitstempel NICHT geändert

Hier sieht man die einzelnen Zeitstempel der originalen (grün, Bild1) und der kopierten (rot, Bild2) Datei.




Kopiert man die Datei auf das interne Dateisystem, in diesem Beispiel nur in ein darunter liegendes Unterverzeichnis so bleibt das Modify Date unberührt.



Und wenn man das ganze z.B. über einen Dateibrowser auf den gleichen SMB Share (in diesem Fall Total Commander) kopiert, wird das Datum (also Modify Date) nicht aktualisiert.







Die Datei wird ja beim Kopiervorgang nicht modifiziert, weshalb ändert sich dann der Zeitstempel von "modify"? Ich hätte erwartet, dass es sich auf der Kommandozeile mit cp -p gleich verhält wie im Dateimanager über die GUI.


Die Fragen, die ich mir stelle, sind folgende:

• Weshalb wird das Modify Date bei Dateien geändert, wenn man sie von der Konsole aus auf ein SMB Share kopiert?
• Warum passiert dies nicht bei leeren Dateien die via touch erstellt wurden?
• Warum wird das Modify Date beim Kopiervorgang auf ein SMB Share über die Kommandozeile via cp -p geändert, aber nicht über die GUI mit einem Dateibrowser des Betriebssystems?

 

[Benares]

So sieht es bei mir aus:

root@DS1522:/volume1/photo/2022_05 (Testordner)# ll
total 50396
d---------+ 1 nasadmin users      132 Dec  3  2022 .
d---------+ 1 root     root      7822 Jun 23 21:22 ..
drwxrwxrwx+ 1 root     root       120 Jun  9 14:55 @eaDir
----------+ 1 nasadmin users 10101248 Mar 29  2022 P1003068.JPG
----------+ 1 nasadmin users  9647616 Mar 29  2022 P1003069.JPG
----------+ 1 nasadmin users 10554368 Mar 29  2022 P1003070.JPG
----------+ 1 nasadmin users 10432512 Mar 29  2022 P1003071.JPG
----------+ 1 nasadmin users 10859520 Mar 29  2022 P1003072.JPG
root@DS1522:/volume1/photo/2022_05 (Testordner)# cp --preserve P1003068.JPG xxx.JPG
root@DS1522:/volume1/photo/2022_05 (Testordner)# ll
total 60264
d---------+ 1 nasadmin users      146 Jun 27 15:42 .
d---------+ 1 root     root      7822 Jun 23 21:22 ..
drwxrwxrwx+ 1 root     root       174 Jun 27 15:42 @eaDir
----------+ 1 nasadmin users 10101248 Mar 29  2022 P1003068.JPG
----------+ 1 nasadmin users  9647616 Mar 29  2022 P1003069.JPG
----------+ 1 nasadmin users 10554368 Mar 29  2022 P1003070.JPG
----------+ 1 nasadmin users 10432512 Mar 29  2022 P1003071.JPG
----------+ 1 nasadmin users 10859520 Mar 29  2022 P1003072.JPG
----------+ 1 nasadmin users 10101248 Mar 29  2022 xxx.JPG
root@DS1522:/volume1/photo/2022_05 (Testordner)# stat P1003068.JPG
  File: P1003068.JPG
  Size: 10101248        Blocks: 19736      IO Block: 4096   regular file
Device: 2bh/43d Inode: 226849      Links: 1
Access: (0000/----------)  Uid: ( 1026/nasadmin)   Gid: (  100/   users)
Access: 2023-06-27 15:42:54.946154632 +0200
Modify: 2022-03-29 09:01:06.000000000 +0200
Change: 2023-06-02 16:34:20.630945959 +0200
 Birth: -
root@DS1522:/volume1/photo/2022_05 (Testordner)# stat xxx.JPG
  File: xxx.JPG
  Size: 10101248        Blocks: 19736      IO Block: 4096   regular file
Device: 2bh/43d Inode: 532039      Links: 1
Access: (0000/----------)  Uid: ( 1026/nasadmin)   Gid: (  100/   users)
Access: 2023-06-27 15:42:54.971154798 +0200
Modify: 2022-03-29 09:01:06.000000000 +0200
Change: 2023-06-27 15:42:54.966154765 +0200
 Birth: -
root@DS1522:/volume1/photo/2022_05 (Testordner)#

Access ist klar, der cp-Befehl liest ja.
Modify bleibt erhalten
und Change bezieht sich wohl auf Rechte und Eigentümer, die wurden wohl auch nachgeführt/geändert, da ich ja als root kopiert habe.
Für mich das plausibel.

Überleg mal in Ruhe, was da bei dir anders sein könnte. Rutscht da evtl. noch irgendeine Photo-Software auf den Bildern rum?

 

[Hagen2000]

Sehr merkwürdig - ich kann das von @luddi beschriebene Verhalten nachvollziehen (macOS 13.4.1). Kopieren über den macOS-Finder macht es richtig, kopieren mit

cp -p

führt zu den beschriebenen Effekten.

 

[luddi]

Überleg mal in Ruhe, was da bei dir anders sein könnte.

@Benares
Danke für dein Beispiel, aber das, was ich bei dir sehe, passiert ja alles direkt auf der DS. Folglich ist Quelle und Ziel auf dem gleichen Dateisystem.
Und das habe ich bereits beschrieben, dass wenn man auf dem gleichen Filesystem Dateien kopiert wie in deinem Beispiel kommt es nicht zu einer Änderung des Modify Date.
Auch bei mir ist das Verhalten in diesem Fall exakt wie bei dir und kann das bestätigen.

Aber mir ging es eigentlich um den Kopiervorgang in Verbindung mit SMB.
In meinem Beispiel habe ich dafür einen Raspberry als Quelle verwendet und habe eine Datei, die auf dem Raspberry Dateisystem liegt (Festplatte EXT4) auf ein SMB Share der Diskstation kopiert. Und genau hierbei über SMB wird beim Kopiervorgang über die Kommandozeile mit cp -p das Modify Date geändert.

Wohingegen, wenn man eine Datei via Dateibrowser auf ein SMB Share kopiert bleibt der Modify Timestamp unberührt.

 

[Benares]

Öhm, verstehe ich grad nicht. Das heißt, die Quelle liegt bei dir auf einem per SMB gemountetem Filesystem extern?

 

[framp]

ich glaube es ist umgekehrt beim TE

 

[Benares]

Also liegt das Ziel remote?

 

[framp]

Ja. So verstehe ich es.

In meinem Beispiel habe ich dafür einen Raspberry als Quelle verwendet und habe eine Datei, die auf dem Raspberry Dateisystem liegt (Festplatte EXT4) auf ein SMB Share der Diskstation kopiert. Und genau hierbei über SMB wird beim Kopiervorgang über die Kommandozeile mit cp -p das Modify Date geändert.

 

[luddi]

Hier nochmals als Bild zum besseren Verständnis.

Folgende Szenarien

1. Kopieren von Host zu Host mit Command Line cp -p
2. Kopieren von Host zu Server via SMB/CIFS Mount mit Dateibrowser (Explorer, Dolphin, Finder etc.)
3. Kopieren von Host zu Server via SMB/CIFS Mount mit Command Line cp -p

Fazit:
Kopiert man eine Datei von Host zu Host über die Kommandozeile mit --preserve, so bleibt der Zeitstempel Modify erhalten.
Kopiert man die gleiche Datei von Host zu Server via SMB mit einem Dateibrowser über die GUI (Windows, Linux, Mac) so bleibt auch hier der Zeitstempel Modify erhalten.
Kopiert man die gleiche Datei wiederum von Host zu Server via SMB über die Kommandozeile, so wird hierbei der Zeitstempel von Modify verändert.

 

[Hagen2000]

So hatte ich es auch von Anfang an verstanden und kann das Verhalten bei mir nachvollziehen.

 

[luddi]

Sehr schön. Ich hoffe, wir konnten mit Post #11 nun auch @Benares abholen

 

[framp]

Ich bin kein Sambaspetzl. Aber in Samba kann man eine Menge konfigurieren. Ich vermute dort gibt es irgendein Setting was das Verhalten fixed. Aber trotzdem ist es merkwürdig dass der Default ein anderes Verhalten zeigt.

 

[luddi]

Nun ja... ich gebe dir recht, dass Samba sehr umfangreich ist. Aber die Frage, die sich mir stellt, weshalb verhält sich ein Kopiervorgang über einen Dateibrowser anders als wie ein cp -p über die Kommandozeile?
Die SMB Konfiguration des Servers ist ja in beiden Fällen identisch, nur der Kopiervorgang von Host zu Server ist über ein anderes Tool.

 

[luddi]

@amarthius @goetz @Marc @NocTec @QTip @steffi
Kann mir bitte einer von euch erklären, weshalb das Zitat aus Beitrag #13 entfernt wurde? Ich würde gerne den Grund kennen, falls es meinerseits ein falsches Verhalten war um solch etwas in Zukunft zu vermeiden.
Eine Aufklärung Eurerseits würde mir hier helfen.

 

[framp]

Das ist eine gute Frage dessen Antwort mich als Maintainer von raspiBackup sehr interessiert

Edit: Meine Antwort bezieht sich auf #15. Aber auch interessiert mich die Antwort zu #16

 

[luddi]

Was sehr interessant ist, wenn man für den Kopiervorgang Cygwin unter Windows verwendet. Somit Szenario Nummer 3 (Kopieren über Command Line via SMB von Host zu Server).

Hier wirft cp folgenden Fehler:

luddi@host: ~ $ cp -p /cygdrive/c/Users/luddi/temp/IMG_9090.jpeg //Synology/<FREIGABE>
cp: preserving times for '//Synology/<FREIGABE>/IMG_9090.jpeg': Permission denied

Wohingegen eine Kopie auf das eigene Dataisystem (Host zu Host, Szenario Nummer 1) einwandfrei klappt, ohne dass der Zeitstempel von Modify verändert wird.

luddi@host: ~ $ cp -p /cygdrive/c/Users/luddi/temp/IMG_9090.jpeg /cygdrive/c/Users/luddi/temp/IMG_9090_XXX.jpeg

Ein "permission denied" für das Beibehalten der Zeitstempel kann ich nicht nachvollziehen. Denn der SMB User, welcher auf die Freigabe schreibt, hat allerdings Schreibberechtigungen.

 

[luddi]

weshalb das Zitat aus Beitrag #13 entfernt wurde

Danke an die Moderatoren die mich hierin aufgeklärt haben.
Es wurde in meiner Antwort ein Zitat verwendet, welches direkt in dem vorherigen Beitrag zu lesen war. Somit diente dies zu keiner Verbesserung des Verständnisses in der Thematik, da ich ja quasi direkt darauffolgend geantwortet hatte.

 

[Hagen2000]

Ich habe weitere Tests durchgeführt und möchte die Ergebnisse hier gerne dokumentieren. Der Kopiervorgang wird dabei vom jeweiligen Host (macOS, Windows etc.) gestartet, Ziel ist jeweils die DS, in der Regel über SMB (CIFS) gemountet. Der beobachtete Fehler äußert sich wie folgt:
Eine leere Datei wird von cp mit korrektem Zeitstempel kopiert, eine nicht-leere Datei erhält - trotz gesetzter Option -p/--preserve - einen aktuellen Zeitstempel.

• macOS 13.4.1, mount per SMB (CIFS): Der Fehler tritt auf.
• macOS 13.4.1, mount per APFS: Der Fehler tritt auf.
• AlmaLinux 8.8, der Fehler tritt auf.
• CentOS 6.10, der Fehler tritt nicht auf!
• Windows 10, mit xcopy tritt der Fehler nicht auf.

Windows läuft hier etwas außerhalb der Wertung, interessant ist aber, dass beim alten CentOS 6 der Fehler nicht auftritt.
Weiterhin bemerkenswert, dass unter macOS der Fehler sowohl mit SMB als auch mit APFS auftritt.
Scheint irgendwie am Verhalten vom cp-Utility zu liegen. Vielleicht mag das mal jemand mit Wireshark o.ä. genauer untersuchen.