Hallo zusammen,
ich möchte jetzt mal mein Problem konkretisieren und hoffe es ist verständlich:
Bereits seit meiner Windows-Zeiten nutze ich ein NAS als Datenspeicher (hauptsächlich Fotos - Ihr wollt nicht wissen wieviel sich da in den letzten Jahren angesammelt hat...) Linux habe ich mit Mint-KDE begonnen, als das eingestellt wurde ging es zu Kubuntu, dann zu Manjaro wegen der besseren Unterstützung neuer Hardware - komprimierte Kurzfassung der letzten 5 Jahre ;-)
Was mir beim Kopieren aufs NAS wichtig ist, ist, dass der ursprüngliche Datei-Änderungs-Zeitstempel bei Dateien erhalten bleibt. Bei Verzeichnissen ist mir das egal. Zur Präzisierung: Wenn ich jetzt vom Zeitstempel schreibe, meine ich immer den "Änderung"s-Zeitstempel (Datum und Uhrzeit).
Nun das Problem: Seit einiger Zeit (genau kann ichs leider nicht eingrenzen) wird beim Kopieren auf das über fstab mit cifs eingebundene NAS der Datei-Zeitstempel aktualisiert, aber der Verzeichnis-Zeitstempel bleibt gleich. Das will und kann ich nicht verstehen.
Auf der Suche nach einer Lösung habe ich alle mir angelesenen Versuche gemacht. Hier eine Auswahl:
- auf einem Testsystem mit SSD-Wechselschacht habe ich jeweils Manjaro, Kubuntu 20.04, Kubuntu 20.10 und KDE-Neon zur Verfügung - Alle Samba-Versionen von 2.0 bis 3.11 (älter als 2.0 scheint mir nicht sinnvoll) durchgetestet - Gefühlt alle Kombinationen und Parameter in der fstab-Zeile getestet aktuell: //192.168.0.127/Freigabe /mnt/mountpunkt cifs user,x-systemd.automount,noauto,iocharset=utf8,username=user,password=geheim,domain=workgroup,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0
Ich hab jetzt viel über uid, gid, file_mode, dir_mode usw. gelernt aber es hat nix geholfen.
Gehe ich mit Dolphin (Dateimanager für Nicht-KDE-ler ;-) ) auf das NAS (wenn ich das richtig verstanden habe, nutzt Dolphin gvfs und nicht cifs) , dann bleibt der Datei-Zeitstempel erhalten, ebenso beim Einbinden über NFS (scheint mir aber keine so tolle Lösung - Kofler hats schon aus seinem Buch geworfen)
Ich muss die NAS-Freigabe über fstab mounten, denn sonst kann ich z. B. mit Darktable nicht auf die Fotos zugreifen.
Bei der Fehlersuche habe ich mich - in Ermangelung tiefgreifender Systemkenntnisse - auf Vergleichen und systematisches probieren beschränkt und bin zu folgenden Ergebnissen gekommen (jeweils bei gleicher fstab):
Bei Kubuntu 20.04 bleiben beim Kopieren (cifs) Datei- und Verzeichnis-Zeitstempel erhalten Bei allen anderen Systemen bleibt der Verzeichnis-Zeitstempel erhalten und der Datei-Zeitstempel wird aktualisiert (genau umgekehrt wie ich es brauche).
Der Vergleich der mtab bringt keinen verwertbaren Unterschied und auch der Vergleich der cifs-util-, Kernel- usw.-Versions-Nummern bringt nichts, denn bei Kubuntu 20.04 und KDE Neon sind sie identisch.
Als schnelle Übergangs-Hilfe habe ich auf mein Produktiv-System manjaro durch Kubuntu 20.04 ersetzt, möchte aber aus einer Reihe von Gründen gerne wieder zurück zu Manjaro, auch wenn es dort unliebsame Überraschungen wie plötzlich vermurkste Cups usw. gibt)
Im Ubuntuusers-Forum habe ich mein Problem auch geschildert, aber leider noch nicht einmal eine Rückmeldung bekommen :-(
Mich interessiert brennend, ob mir jemand einen Tipp geben kann, an welchen Parameter ich drehen kann, damit unter Manjaro, KDE Neon oder Kubuntu 20.10 die Kopiererei auf NAS (für mich) richtig funktioniert.
Ich vermute, dass ich irgendeine Kleinigkeit vergleichbar mit Arnos FAT32-/exFAT-Problem übersehe.
Ich fürchte, dass früher oder später das Problem auch bei ()ubuntu 20.04 auch auftritt.
Ach ja, ich vergaß noch: Das Problem tritt sowohl bei OpenMediaVault, als auch bei einem QNAP-NAS auf, dürfte daher nicht am NAS liegen
Helfen würden mir auch Rückmeldungen, die das Problem bestätigen bzw. dementieren, denn mehr Versuchssysteme möchte ich nicht ausprobieren...
@ Arno: ich hab Dein SMB-Problem noch nicht ganz verstanden, aber hilft Dir evtl. OpenMediaVault auf den Server zu installieren? Das läuft bei mir seit zwei Jahren störungsfrei - ein paar Tricks kenne ich da auch ;-)
Viele frustrierte Grüße,
Benno
Am 20.12.20 um 12:47 schrieb Arno:
Ja, dann Benno ... willkommen!
Frustmomente gibt es immer mal, egal mit welchem OS. Aber die Freude eines der Problem losgeworden zu sein ist dann natürlich um so größer. Wenn alles gleich klappt ist auch langweilig ;)
Ich muss jetzt auch noch ein iPhone "administrieren" - alles wieder ganz anders und gut gekapselt. Jemand schon mal mit "airmore" Erfahrung gemacht - gibts auch unter Android? Kostenlos und keine Werbung, da muss man schon mal genauer hinschauen ;) Aber Dateien mit dem Rechner ohne Kabel/Cloud zu tauschen ist ne prima Sache...
Mit SMB/CIFS bin ich auch nicht der Auskenner. Gerade soll ich ein Gerät mit Uralt - 2.6er Kernel, der nur SMB1 kann auf SMB2 oder besser 3 hochrüsten. Vielleicht ist dein Problem das eines der Geräte nur einen der Dialekte spricht und SMB1 ist inzwischen oft nicht mehr unterstützt? Aber bei deinem Anlauf ist es sicher was vieeel komplizierteres.
Hat schon mal jemand damit https://github.com/sahlberg/libsmb2 Erfahrung, es sogar cross compiliert? Muss erst mal lernen was es mit dem cmake auf sich hat.
Dann euch allen schöne Feiertage und bleibt gesund,
Arno
On 19.12.20 19:36, btux wrote:
Hallo Arno, hallo Andreas,
vielen Dank für die Blumen (bzw. die Nadel) und die Rückmeldung - beides ist leider nicht mehr selbstverständlich.
Ich freue mich, wenn ich helfen kann - und wenn es mir auch hilft umso besser ;-)
Auf diesem Weg möchte ich auch kurz Hallo sagen. Ich bin Benno und komme aus Nordhessen. Zu Euch hat mich der Zufall in Person von Clemens S. gebracht. Mehr dann mal bei Gelegenheit bzw. Interesse. Ich bin anwendender Praktiker, der alles was mit Programmierung zu tun hat als notwendiges Übel betrachtet und tausendmal lieber den Schraubendreher und Lötkolben schwingt :-) Mit Linux arbeite ich seit ca. 5 Jahren und befinde mich gerade in einer ziemlichen Frust-Talsohle (s. u.)
Als ich mich in Eure Mailling-Liste letzten Samstag eingetragen hatte, kam dann gleich Arnos Problem, was nach kurzer Überprüfung leider auch meins wurde. Ich dachte "och nee noch so ein krudes Problem, mein Samba-/ cifs-Problem reicht mir doch.."
Glücklicherweise ließ sich Arnos Problem viel schneller lösen als das, was mich schon einige Wochen Frust gekostet hat. In den nächsten Tagen möchte ich es Euch zur Diskussion stellen.
Ob und wie Arnos Problem als bug gemeldet werden kann, würde ich gerne jemanden überlassen, der sich damit auskennt.
Ich würde mich freuen, wenn ich aus dem (von Euch aus gesehen) hohen Norden bei Euch mitmachen kann,
viele Grüße,
Benno
Am 19.12.20 um 16:36 schrieb Andreas Delleske:
Hi Benno,
Bei 32-GB-Speicherkarten ist alles in Ordung. Bei 64-GB-Speicherkarten tritt der Fehler auf.
Nachdem ich die Karten verglichen habe, stellte ich fest, dass die 32-GB-Karte in der Kamera mit Fat32 formatiert wird. Die 64 GB-Karte aber mit exFat. Die exFat-utils fehlen aber bei Kubuntu 20.04. Nachdem ich die mit:
sudo apt-get install exfat-utils
installiert habe, funktioniert es bei mir auch mit 64-GB-Karten einwandfrei.
Wow! Da hast Du Dir die auf jeden Fall die Goldene Ehrennadel in Silber des FLUG verdient!
Ich muß schon gestehen an Fileformate hätt ich auch denken können aber ich dachte die Treiber können doch nicht so buggy sein.
Nun müßte man einen Bugreport bei FAT32 reingeben, aber wo genau?
Hi Benno,
Was mir beim Kopieren aufs NAS wichtig ist, ist, dass der ursprüngliche Datei-Änderungs-Zeitstempel bei Dateien erhalten bleibt.
Klar!
Ich habe ein OMV 5.5.18 im Einsatz, Shares sind auf einem ext4-Dateisystem, SSD, ganz normal.
ich hab gerade ein Foto das ich um 19:08 CET gemacht habe, dann auf meinem Mac kopiert habe auf eine Samba-Freigabe geworfen und wenn ich mit der Commandline nachgucke wird mir dasselbe Datum und Uhrzeit korrekt angezeigt.
Nie hat sich die Uhrzeit verändert.
Ich habe auch noch ein QNAP, da wird das Datum auf der Share auch nicht geändert (wär ja noch schöner). Per ssh komm ich da so schnell nicht rein jetzt.
Zur Präzisierung: Wenn ich jetzt vom Zeitstempel schreibe, meine ich immer den "Änderung"s-Zeitstempel (Datum und Uhrzeit).
Hm.. bisher habe ich vermutlich nur den "creation" gesehen.
Müßte mich jetzt erst einlesen wie ich an die anderen komme..
Schönen Gruß Andreas
Hallo Andreas,
oh, das ging ja schnell, vielen Dank für die Rückmeldung!
So wie es bei Dir funktioniert ist es ja auch richtig (für mich jedenfalls).
Ich hoffe, ich habe jetzt mit meiner Zeitstempel-Bezeichnung nichts falsches geschrieben. In Dolphin gibts "geändert", "erstellt" und "letzter Zugriff"
Die beiden letzteren werden auch beim Kopieren aktualisiert - ist auch nachvollziehbar weil neu auf dem NAS erstellt. So habe ich die Logik verstanden. Der Zeitstempel "geändert" soll (und bleibt bei 20.04) auf dem ursprünglichen Datum. Also genau so wie bei Dir.
Ich hoffe, wir schreiben jetzt von den gleichen Zeitstempeln
Mint basiert doch auch auf Ubuntu bzw. Debian welche Version benutzt Du? Vielleicht versuche ich ja noch ein 5. System.
Hab mir gerade mal schnell Nemo installiert. Dort kannst Du in der Listenansicht in der Kopfzeile der Liste "Änderungsdatum", "Erstelldatum" und "Zugriffsdatum" auswählen. Dann werden alle drei Daten angezeigt.
Viele Grüße,
Benno
Am 21.12.20 um 19:58 schrieb Andreas Delleske:
Hi Benno,
Was mir beim Kopieren aufs NAS wichtig ist, ist, dass der ursprüngliche Datei-Änderungs-Zeitstempel bei Dateien erhalten bleibt.
Klar!
Ich habe ein OMV 5.5.18 im Einsatz, Shares sind auf einem ext4-Dateisystem, SSD, ganz normal.
ich hab gerade ein Foto das ich um 19:08 CET gemacht habe, dann auf meinem Mac kopiert habe auf eine Samba-Freigabe geworfen und wenn ich mit der Commandline nachgucke wird mir dasselbe Datum und Uhrzeit korrekt angezeigt.
Nie hat sich die Uhrzeit verändert.
Ich habe auch noch ein QNAP, da wird das Datum auf der Share auch nicht geändert (wär ja noch schöner). Per ssh komm ich da so schnell nicht rein jetzt.
Zur Präzisierung: Wenn ich jetzt vom Zeitstempel schreibe, meine ich immer den "Änderung"s-Zeitstempel (Datum und Uhrzeit).
Hm.. bisher habe ich vermutlich nur den "creation" gesehen.
Müßte mich jetzt erst einlesen wie ich an die anderen komme..
Schönen Gruß Andreas
Hallo Benno,
On 12/21/20 7:26 PM, btux wrote:
ich möchte jetzt mal mein Problem konkretisieren und hoffe es ist verständlich:
Bereits seit meiner Windows-Zeiten nutze ich ein NAS als Datenspeicher (hauptsächlich Fotos - Ihr wollt nicht wissen wieviel sich da in den letzten Jahren angesammelt hat...) Linux habe ich mit Mint-KDE begonnen, als das eingestellt wurde ging es zu Kubuntu, dann zu Manjaro wegen der besseren Unterstützung neuer Hardware - komprimierte Kurzfassung der letzten 5 Jahre ;-)
Was mir beim Kopieren aufs NAS wichtig ist, ist, dass der ursprüngliche Datei-Änderungs-Zeitstempel bei Dateien erhalten bleibt. Bei Verzeichnissen ist mir das egal. Zur Präzisierung: Wenn ich jetzt vom Zeitstempel schreibe, meine ich immer den "Änderung"s-Zeitstempel (Datum und Uhrzeit).
Also das was
stat -c %y /path/to/file
ausgibt, richtig?
Nun das Problem: Seit einiger Zeit (genau kann ichs leider nicht eingrenzen) wird beim Kopieren auf das über fstab mit cifs eingebundene NAS der Datei-Zeitstempel aktualisiert, aber der Verzeichnis-Zeitstempel bleibt gleich. Das will und kann ich nicht verstehen.
Auf der Suche nach einer Lösung habe ich alle mir angelesenen Versuche gemacht. Hier eine Auswahl:
- auf einem Testsystem mit SSD-Wechselschacht habe ich jeweils Manjaro,
Kubuntu 20.04, Kubuntu 20.10 und KDE-Neon zur Verfügung
- Alle Samba-Versionen von 2.0 bis 3.11 (älter als 2.0 scheint mir nicht
sinnvoll) durchgetestet
- Gefühlt alle Kombinationen und Parameter in der fstab-Zeile getestet
aktuell: //192.168.0.127/Freigabe /mnt/mountpunkt cifs user,x-systemd.automount,noauto,iocharset=utf8,username=user,password=geheim,domain=workgroup,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0
Also hast Du das NAS immer gleich gelassen und nur der SMB-Client wurde variiert, richtig? Wie kopierst Du denn? Mit irgendeinem GUI-Tool, oder mit cp? Probiere mal auf der Komando-Zeile, also etwa:
stat -c %y /mnt/mountpunkt/somefile cp -a /mnt/mountpunkt/somefile /mnt/mountpunkt/someotherfile stat -c %y /mnt/mountpunkt/someotherfile
Ich hab jetzt viel über uid, gid, file_mode, dir_mode usw. gelernt aber es hat nix geholfen.
Gehe ich mit Dolphin (Dateimanager für Nicht-KDE-ler ;-) ) auf das NAS (wenn ich das richtig verstanden habe, nutzt Dolphin gvfs und nicht cifs) , dann bleibt der Datei-Zeitstempel erhalten, ebenso beim Einbinden über NFS (scheint mir aber keine so tolle Lösung - Kofler hats schon aus seinem Buch geworfen)
Meine Vermutung ist, dass das weniger mit dem eingebundenen Dateisystem zu tun hat, sondern mehr mit dem Programm, das die Kopien macht. Das sollte der obige Test aufdecken können.
Ich muss die NAS-Freigabe über fstab mounten, denn sonst kann ich z. B. mit Darktable nicht auf die Fotos zugreifen.
Echt? Das klingt komisch. Dass Darktable nicht mir gvfs ungehen kann: von mir aus. Aber ein usermount oder was mit fuse sollte doch auch gehen.
Liebe Grüße Uwe
Hallo Uwe,
danke fürs einklinken! Hier meine Antworten:
Am 22.12.20 um 07:46 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/21/20 7:26 PM, btux wrote:
ich möchte jetzt mal mein Problem konkretisieren und hoffe es ist verständlich:
Bereits seit meiner Windows-Zeiten nutze ich ein NAS als Datenspeicher (hauptsächlich Fotos - Ihr wollt nicht wissen wieviel sich da in den letzten Jahren angesammelt hat...) Linux habe ich mit Mint-KDE begonnen, als das eingestellt wurde ging es zu Kubuntu, dann zu Manjaro wegen der besseren Unterstützung neuer Hardware - komprimierte Kurzfassung der letzten 5 Jahre ;-)
Was mir beim Kopieren aufs NAS wichtig ist, ist, dass der ursprüngliche Datei-Änderungs-Zeitstempel bei Dateien erhalten bleibt. Bei Verzeichnissen ist mir das egal. Zur Präzisierung: Wenn ich jetzt vom Zeitstempel schreibe, meine ich immer den "Änderung"s-Zeitstempel (Datum und Uhrzeit).
Also das was
stat -c %y /path/to/file
ausgibt, richtig?
Korrekt, genau diese Zeitangabe meine ich.
Nun das Problem: Seit einiger Zeit (genau kann ichs leider nicht eingrenzen) wird beim Kopieren auf das über fstab mit cifs eingebundene NAS der Datei-Zeitstempel aktualisiert, aber der Verzeichnis-Zeitstempel bleibt gleich. Das will und kann ich nicht verstehen.
Auf der Suche nach einer Lösung habe ich alle mir angelesenen Versuche gemacht. Hier eine Auswahl:
- auf einem Testsystem mit SSD-Wechselschacht habe ich jeweils
Manjaro, Kubuntu 20.04, Kubuntu 20.10 und KDE-Neon zur Verfügung
- Alle Samba-Versionen von 2.0 bis 3.11 (älter als 2.0 scheint mir
nicht sinnvoll) durchgetestet
- Gefühlt alle Kombinationen und Parameter in der fstab-Zeile getestet
aktuell: //192.168.0.127/Freigabe /mnt/mountpunkt cifs user,x-systemd.automount,noauto,iocharset=utf8,username=user,password=geheim,domain=workgroup,uid=1000,gid=1000,file_mode=0644,dir_mode=0755 0 0
Also hast Du das NAS immer gleich gelassen und nur der SMB-Client wurde variiert, richtig? Wie kopierst Du denn? Mit irgendeinem GUI-Tool, oder mit cp? Probiere mal auf der Komando-Zeile, also etwa:
Bei beiden NAS wurde nichts verändert. Auf den Clients habe ich nur verschiedene Distributionen mit immer gleicher fstab (uid und gid natürlich angepasst) verwendet. Ich kopiere mit GUI-Tools wie Dolphin, Krusader und Nemo - alle verhalten sich gleich. Von der Kommando-Zeile bin ich beim Kopieren weitestgehend entwöhnt.
stat -c %y /mnt/mountpunkt/somefile cp -a /mnt/mountpunkt/somefile /mnt/mountpunkt/someotherfile stat -c %y /mnt/mountpunkt/someotherfile
Jetzt wird es interessant:
Wenn ich von einer Quelle auf das NAS mit cp kopiere wird das Datum aktualisiert (bei allen Systemen gleich), wenn ich zwischen Verzeichnissen der Festplatte des Client kopieren nicht (auch bei allen Systemen gleich)
Ich hab jetzt viel über uid, gid, file_mode, dir_mode usw. gelernt aber es hat nix geholfen.
Gehe ich mit Dolphin (Dateimanager für Nicht-KDE-ler ;-) ) auf das NAS (wenn ich das richtig verstanden habe, nutzt Dolphin gvfs und nicht cifs) , dann bleibt der Datei-Zeitstempel erhalten, ebenso beim Einbinden über NFS (scheint mir aber keine so tolle Lösung - Kofler hats schon aus seinem Buch geworfen)
Meine Vermutung ist, dass das weniger mit dem eingebundenen Dateisystem zu tun hat, sondern mehr mit dem Programm, das die Kopien macht. Das sollte der obige Test aufdecken können.
Klingt interessant und wäre ein Lösungsweg, den ich allerdings (noch) nicht durchblicke ;-)
Ich muss die NAS-Freigabe über fstab mounten, denn sonst kann ich z. B. mit Darktable nicht auf die Fotos zugreifen.
Echt? Das klingt komisch. Dass Darktable nicht mir gvfs ungehen kann: von mir aus. Aber ein usermount oder was mit fuse sollte doch auch gehen.
OK, das müsste ich mir dann noch genauer anschauen, aber im Moment bleibe ich noch ein wenig in das Problem verbissen :-)
Liebe Grüße Uwe
Viele Grüße,
Benno
Hallo Benno,
On 12/22/20 6:04 PM, btux wrote:
Am 22.12.20 um 07:46 schrieb Uwe Kleine-König:
On 12/21/20 7:26 PM, btux wrote:
ich möchte jetzt mal mein Problem konkretisieren und hoffe es ist verständlich: [...]
stat -c %y /mnt/mountpunkt/somefile cp -a /mnt/mountpunkt/somefile /mnt/mountpunkt/someotherfile stat -c %y /mnt/mountpunkt/someotherfile
Jetzt wird es interessant:
Wenn ich von einer Quelle auf das NAS mit cp kopiere wird das Datum aktualisiert (bei allen Systemen gleich), wenn ich zwischen Verzeichnissen der Festplatte des Client kopieren nicht (auch bei allen Systemen gleich)
Eigentlich(tm) würde ich erwarten, dass cp -a versucht, den modification timestamp zu erhalten.
Ich habe kein samba-Share hier, aber auf meinem btrfs funktioniert das so wie ich das erwarte:
lala anlegen:
uwe@taurus:/tmp$ touch lala
modification timestamp ausgeben:
uwe@taurus:/tmp$ stat -c %y lala 2020-12-22 18:35:09.582758372 +0100
modification timestamp ändern:
uwe@taurus:/tmp$ touch -m -t 202001020304 lala uwe@taurus:/tmp$ stat -c %y lala 2020-01-02 03:04:00.000000000 +0100
lala nach lolo kopieren und timestamp prüfen:
uwe@taurus:/tmp$ cp -a lala lolo uwe@taurus:/tmp$ stat -c %y lolo 2020-01-02 03:04:00.000000000 +0100
wie erwartet bleibt der erhalten.
Funktioniert das auf Deinem samba-Share auch so?
Liebe Grüße Uwe
Hallo Uwe,
das ist genau das Problem:
Wenn ich auf dem Client eine Datei mit cp von einem Verzeichnis zum anderen kopiere, oder eine Datei dupliziere, dann bleibt der timestamp erhalten.
Sobald ich von wo auch immer auf einen Samba-Share kopiere (auch innerhalb des Share z. B. zwischen zwei Verzeichnissen) wird der Zeitstempel aktualisiert.
Wohlgemerkt wenn ich mit cp, wie Du beschrieben hast, kopiere.
Mit einem Dateimanager (Dolphin, Nemo oder Krusader) wird der Zeitstempel bei Manjaro, KDE-Neon und Kubuntu 20.10 aktualisiert.
Bei Kubuntu 20.04 und Mint 20 bleibt die Zeit erhalten.
Ich hoffe ganz naiv auf einen "Schalter" in einer Konfigurationsdatei, einen Treiber o. ä., denn Kubuntu 20.04, Mint 20 und KDE-Neon haben nach meinen Infos den gleichen Ubuntu-Unterbau (Kernel, cifs-utils usw.) und verhalten sich trotzdem unterschiedlich. Irgendetwas muss ja z. B. bei KDE-Neon gegenüber Kubuntu verändert sein, ich habe aber keine Idee und Ahnung, wo ich suchen soll.
Ich befürchte einfach, dass das Problem bei Kubuntu 20.04 und Mint irgendwann auch auftritt, deswegen habe ich mich da so festgebissen.
Viele Grüße,
Benno
Am 22.12.20 um 18:41 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/22/20 6:04 PM, btux wrote:
Am 22.12.20 um 07:46 schrieb Uwe Kleine-König:
On 12/21/20 7:26 PM, btux wrote:
ich möchte jetzt mal mein Problem konkretisieren und hoffe es ist verständlich: [...]
stat -c %y /mnt/mountpunkt/somefile cp -a /mnt/mountpunkt/somefile /mnt/mountpunkt/someotherfile stat -c %y /mnt/mountpunkt/someotherfile
Jetzt wird es interessant:
Wenn ich von einer Quelle auf das NAS mit cp kopiere wird das Datum aktualisiert (bei allen Systemen gleich), wenn ich zwischen Verzeichnissen der Festplatte des Client kopieren nicht (auch bei allen Systemen gleich)
Eigentlich(tm) würde ich erwarten, dass cp -a versucht, den modification timestamp zu erhalten.
Ich habe kein samba-Share hier, aber auf meinem btrfs funktioniert das so wie ich das erwarte:
lala anlegen:
uwe@taurus:/tmp$ touch lala
modification timestamp ausgeben:
uwe@taurus:/tmp$ stat -c %y lala 2020-12-22 18:35:09.582758372 +0100
modification timestamp ändern:
uwe@taurus:/tmp$ touch -m -t 202001020304 lala uwe@taurus:/tmp$ stat -c %y lala 2020-01-02 03:04:00.000000000 +0100
lala nach lolo kopieren und timestamp prüfen:
uwe@taurus:/tmp$ cp -a lala lolo uwe@taurus:/tmp$ stat -c %y lolo 2020-01-02 03:04:00.000000000 +0100
wie erwartet bleibt der erhalten.
Funktioniert das auf Deinem samba-Share auch so?
Liebe Grüße Uwe
Hallo Benno,
On 12/22/20 7:46 PM, btux wrote:
das ist genau das Problem:
Wenn ich auf dem Client eine Datei mit cp von einem Verzeichnis zum anderen kopiere, oder eine Datei dupliziere, dann bleibt der timestamp erhalten.
Hast Du mal probiert, den timestamp einer mit touch zu setzen? Wenn das nicht geht ist klar, dass cp -a das auch nicht kann.
Liebe Grüße Uwe
Hallo Uwe,
touch funktioniert auf allen Systemen auf dem NAS wie es soll.
Schade, war ein interessanter Ansatz.
Ich habe nochmal den Kopiervorgang im Dateimanager genau beobachtet. Solange die Datei noch kopiert wird ist der Zeitstempel auf der aktuellen Uhrzeit. Erst nach abgeschlossener Kopie wird er bei Kubuntu 20.04 und Mint auf die Zeit der Quelldatei geändert. Dieser letzte Schritt fehlt bei den anderen Systemen und cp.
Ich bin weiter ratlos....
Viele Grüße, Benno
Am 22.12.20 um 22:09 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/22/20 7:46 PM, btux wrote:
das ist genau das Problem:
Wenn ich auf dem Client eine Datei mit cp von einem Verzeichnis zum anderen kopiere, oder eine Datei dupliziere, dann bleibt der timestamp erhalten.
Hast Du mal probiert, den timestamp einer mit touch zu setzen? Wenn das nicht geht ist klar, dass cp -a das auch nicht kann.
Liebe Grüße Uwe
Hallo Benno,
On 12/23/20 7:06 AM, btux wrote:
touch funktioniert auf allen Systemen auf dem NAS wie es soll.
Kannst du mal eine kleine Datei lokal auf Deiner Maschine anlegen und die dann mit cp -a auf das NAS kopieren und vom cp ein strace schicken, also etwa:
echo Hallo > somefile touch -m -t 202001020304 somefile strace -o /tmp/trace-cp -fv cp -a somefile /mnt/meinnas/tralala
und mir (ich schlage vor per PM und nicht auf die Liste wegen der Dateigröße) die Datei /tmp/trace-cp schicken?
Liebe Grüße Uwe
Hallo zusammen,
das Problem ist gelöst, dazu aber weiter unten mehr, denn erst einmal:
Vielen herzlichen Dank an alle, die mir geholfen haben den richtigen Lösungsweg zu finden, besonders:
- Clemens S. für den netten Erstkontakt und die Info über Eure Gruppe, - Arno für den Versuch, unser beider Problem zu lösen und die Aufmunterung für mein Problem weiter zu suchen, - Andreas für den Anstoß Mint Cinnamon 20 mal anzuschauen und - Uwe für die Anregungen mal wieder die Kommandozeile zu benutzen und damit in eine andere Richtung zu denken.
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Da ich mich über KDE schon eine Weile geärgert habe (u. a. Dolphin kann nicht mehr mit sudo gestartet werden, Admin-Funktionen wurden kastriert usw.) werde ich zukünftig mit Cinnamon arbeiten. Ich werde aber Manjaro trotz des (mittlerweile gelösten) Cups-Problems treu bleiben, da die Integration von Wine hier für mich einfacher ist und ich einige Win-Programme schlicht brauche (z. B. Helicon Focus, PDF-XChange usw.).
Jetzt muss ich erstmal meinen SSD-Salat ordnen und sortieren, denn sechs verschiedene Systeme sind mir auf Dauer zu viele ;-) Für solche Versuche kann ich einen Laufwerk-Wechselschacht sehr empfehlen.
Also, nochmals vielen Dank, ohne Eure Anregungen hätte ich die Lösung bestimmt nicht so schnell gefunden. Ich möchte mich am 15.01. gerne online bei Euch einklinken. Vielleicht sieht man sich ja ;-)
Euch allen auch Schöne Weihnachten (ich hab sie ja jetzt schon), einen guten Rutsch und das alles Corona-frei.
Viele Grüße aus Nordhessen, Benno
Am 23.12.20 um 12:05 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/23/20 7:06 AM, btux wrote:
touch funktioniert auf allen Systemen auf dem NAS wie es soll.
Kannst du mal eine kleine Datei lokal auf Deiner Maschine anlegen und die dann mit cp -a auf das NAS kopieren und vom cp ein strace schicken, also etwa:
echo Hallo > somefile touch -m -t 202001020304 somefile strace -o /tmp/trace-cp -fv cp -a somefile /mnt/meinnas/tralala
und mir (ich schlage vor per PM und nicht auf die Liste wegen der Dateigröße) die Datei /tmp/trace-cp schicken?
Liebe Grüße Uwe
Hallo Benno,
On 12/23/20 7:11 PM, btux wrote:
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Mein Kriterium für "gelöst" erfüllt das noch nicht. Da ist ja noch keine Erklärung mit drin, warum es mit cp -a nicht auch zum Erhalt der Zeitstempel kam.
Liebe Grüße Uwe
Hallo Uwe,
aus der cp- Problemstellung heraus hast Du völlig recht. Die Hintergründe interessieren mich auch, da können wir gerne noch dran bleiben.
Ich wollte mit meinem Freudensprung nur vermeiden, dass Du u. U. unnötig an einem Problem arbeitest, was in der ursprünglichen Fragestellung gelöst ist. Ich laboriere daran ja schon einige frustrierte Wochen rum.
Meine System-SSD-Sammlung werde ich noch nicht vollständig auflösen, so dass wir gerne noch weiter testen können. Ein Ansatz wäre jetzt auch noch eine NFS-Freigabe mit Samba/cifs zu Vergleichen.
Zu weiteren Experimenten komme ich aber erst nächste Woche. Ich muss jetzt erst einmal wieder ein funktionierendes Produktivsystem aufbauen.
Ich melde mich und schreibe die Ergebnisse. Wenn Du noch weitere Test-Ideen hast, lass sie mich wissen.
Viele Grüße und frohe Weihnachten,
Benno
Am 23.12.20 um 22:43 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/23/20 7:11 PM, btux wrote:
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Mein Kriterium für "gelöst" erfüllt das noch nicht. Da ist ja noch keine Erklärung mit drin, warum es mit cp -a nicht auch zum Erhalt der Zeitstempel kam.
Liebe Grüße Uwe
Hallo Uwe,
nachdem alle Rechner uminstalliert sind, hier meine Textergebnisse:
Kubuntu 18.04 : cp -a auf NAS(cifs) verändert den Zeitstempel ()ubuntu 20.04 und .10 cp -a auf NAS(cifs) verändert den Zeitstempel Manjaro KDE und Cinnamon cp -a auf NAS(cifs) verändert den Zeitstempel
Manjaro KDE und Cinnamon cp -a auf NAS(NFS) Zeitstempel bleibt erhalten.
Da hat cifs wohl schon eine ganze Weile einen Bug - oder sollte das Absicht sein?
rsync stellt bei entsprechendem Schalter (ich nutze Grsync) den Zeitstempel korrekt wieder her.
Viele Grüße, Benno
Am 24.12.20 um 08:09 schrieb btux:
Hallo Uwe,
aus der cp- Problemstellung heraus hast Du völlig recht. Die Hintergründe interessieren mich auch, da können wir gerne noch dran bleiben.
Ich wollte mit meinem Freudensprung nur vermeiden, dass Du u. U. unnötig an einem Problem arbeitest, was in der ursprünglichen Fragestellung gelöst ist. Ich laboriere daran ja schon einige frustrierte Wochen rum.
Meine System-SSD-Sammlung werde ich noch nicht vollständig auflösen, so dass wir gerne noch weiter testen können. Ein Ansatz wäre jetzt auch noch eine NFS-Freigabe mit Samba/cifs zu Vergleichen.
Zu weiteren Experimenten komme ich aber erst nächste Woche. Ich muss jetzt erst einmal wieder ein funktionierendes Produktivsystem aufbauen.
Ich melde mich und schreibe die Ergebnisse. Wenn Du noch weitere Test-Ideen hast, lass sie mich wissen.
Viele Grüße und frohe Weihnachten,
Benno
Am 23.12.20 um 22:43 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/23/20 7:11 PM, btux wrote:
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Mein Kriterium für "gelöst" erfüllt das noch nicht. Da ist ja noch keine Erklärung mit drin, warum es mit cp -a nicht auch zum Erhalt der Zeitstempel kam.
Liebe Grüße Uwe
On 12/28/20 3:54 PM, btux wrote:
Hallo Uwe,
nachdem alle Rechner uminstalliert sind, hier meine Textergebnisse:
Kubuntu 18.04 : cp -a auf NAS(cifs) verändert den Zeitstempel ()ubuntu 20.04 und .10 cp -a auf NAS(cifs) verändert den Zeitstempel Manjaro KDE und Cinnamon cp -a auf NAS(cifs) verändert den Zeitstempel
Und kannst Du mit
touch -m -t 202012241800 /path/to/file
den Timestamp einer Datei in einem per cifs gemountetes Dateisystem ändern?
Liebe Grüße Uwe
Ja, das funktioniert einwandfrei. Ich würde jetzt daraus schließen, dass cp touch nicht nutzt bzw. eigenen code hat.
Am 28.12.20 um 16:06 schrieb Uwe Kleine-König:
On 12/28/20 3:54 PM, btux wrote:
Hallo Uwe,
nachdem alle Rechner uminstalliert sind, hier meine Textergebnisse:
Kubuntu 18.04 : cp -a auf NAS(cifs) verändert den Zeitstempel ()ubuntu 20.04 und .10 cp -a auf NAS(cifs) verändert den Zeitstempel Manjaro KDE und Cinnamon cp -a auf NAS(cifs) verändert den Zeitstempel
Und kannst Du mit
touch -m -t 202012241800 /path/to/file
den Timestamp einer Datei in einem per cifs gemountetes Dateisystem ändern?
Liebe Grüße Uwe
On 12/28/20 4:18 PM, btux wrote:
Ja, das funktioniert einwandfrei. Ich würde jetzt daraus schließen, dass cp touch nicht nutzt bzw. eigenen code hat.
Dann schick mal bitte den strace-Output, den ich neulich (Mail vom 23. gegen Mittag) angefragt habe. Dann sollte auch klar werden, wo der Fehler liegt (entweder im Kernel oder (wahrscheinlicher) in cp).
Was sagt
cp --version
bei Dir?
Liebe Grüße Uwe
Hallo Manuel,
wenn die nachstehende Mail Dir weiterhilft, gerne.
VG Clemens
-------- Weitergeleitete Nachricht -------- Betreff: Gelöst!!! Samba-/ cifs-Problem Datum: Wed, 23 Dec 2020 19:11:30 +0100 Von: btux btux@posteo.org An: Uwe Kleine-König uwe@kleine-koenig.org, Andreas Delleske delleske@vauban.de, epsi@gmx.de, flug@lug-freiburg.de
Hallo zusammen,
das Problem ist gelöst, dazu aber weiter unten mehr, denn erst einmal:
Vielen herzlichen Dank an alle, die mir geholfen haben den richtigen Lösungsweg zu finden, besonders:
- Clemens S. für den netten Erstkontakt und die Info über Eure Gruppe, - Arno für den Versuch, unser beider Problem zu lösen und die Aufmunterung für mein Problem weiter zu suchen, - Andreas für den Anstoß Mint Cinnamon 20 mal anzuschauen und - Uwe für die Anregungen mal wieder die Kommandozeile zu benutzen und damit in eine andere Richtung zu denken.
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Da ich mich über KDE schon eine Weile geärgert habe (u. a. Dolphin kann nicht mehr mit sudo gestartet werden, Admin-Funktionen wurden kastriert usw.) werde ich zukünftig mit Cinnamon arbeiten. Ich werde aber Manjaro trotz des (mittlerweile gelösten) Cups-Problems treu bleiben, da die Integration von Wine hier für mich einfacher ist und ich einige Win-Programme schlicht brauche (z. B. Helicon Focus, PDF-XChange usw.).
Jetzt muss ich erstmal meinen SSD-Salat ordnen und sortieren, denn sechs verschiedene Systeme sind mir auf Dauer zu viele ;-) Für solche Versuche kann ich einen Laufwerk-Wechselschacht sehr empfehlen.
Also, nochmals vielen Dank, ohne Eure Anregungen hätte ich die Lösung bestimmt nicht so schnell gefunden. Ich möchte mich am 15.01. gerne online bei Euch einklinken. Vielleicht sieht man sich ja ;-)
Euch allen auch Schöne Weihnachten (ich hab sie ja jetzt schon), einen guten Rutsch und das alles Corona-frei.
Viele Grüße aus Nordhessen, Benno
Am 23.12.20 um 12:05 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/23/20 7:06 AM, btux wrote:
touch funktioniert auf allen Systemen auf dem NAS wie es soll.
Kannst du mal eine kleine Datei lokal auf Deiner Maschine anlegen und die dann mit cp -a auf das NAS kopieren und vom cp ein strace schicken, also etwa:
echo Hallo > somefile touch -m -t 202001020304 somefile strace -o /tmp/trace-cp -fv cp -a somefile /mnt/meinnas/tralala
und mir (ich schlage vor per PM und nicht auf die Liste wegen der Dateigröße) die Datei /tmp/trace-cp schicken?
Liebe Grüße Uwe
Danke :-)
Mit freundlichen Grüßen
Manuel Ohnemus Dipl. Ing. (FH)
Konstruktion und Betriebsmittel Ohnemus Hauptstraße 72 D-77960 Seelbach Tel: +49 7823 961238-1 Fax: +49 7823 961238-4 manuel.ohnemus@kb-ohnemus.de https://www.kb-ohnemus.de
Am 10.05.21 um 11:43 schrieb ctux@dismail.de:
Hallo Manuel,
wenn die nachstehende Mail Dir weiterhilft, gerne.
VG Clemens
-------- Weitergeleitete Nachricht -------- Betreff: Gelöst!!! Samba-/ cifs-Problem Datum: Wed, 23 Dec 2020 19:11:30 +0100 Von: btux btux@posteo.org An: Uwe Kleine-König uwe@kleine-koenig.org, Andreas Delleske delleske@vauban.de, epsi@gmx.de, flug@lug-freiburg.de
Hallo zusammen,
das Problem ist gelöst, dazu aber weiter unten mehr, denn erst einmal:
Vielen herzlichen Dank an alle, die mir geholfen haben den richtigen Lösungsweg zu finden, besonders:
- Clemens S. für den netten Erstkontakt und die Info über Eure Gruppe,
- Arno für den Versuch, unser beider Problem zu lösen und die
Aufmunterung für mein Problem weiter zu suchen,
- Andreas für den Anstoß Mint Cinnamon 20 mal anzuschauen und
- Uwe für die Anregungen mal wieder die Kommandozeile zu benutzen und
damit in eine andere Richtung zu denken.
Und jetzt die Auflösung:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Weil ich dem Braten noch nicht so richtig getraut habe, habe ich mir noch zwei SSDs geschnappt und Ubunut-Mate 20.10 und Manjaro Cinnamon installiert und gegengetestet. Siehe da: Der Zeitstempel bleibt wie gewünscht erhalten.
Da ich mich über KDE schon eine Weile geärgert habe (u. a. Dolphin kann nicht mehr mit sudo gestartet werden, Admin-Funktionen wurden kastriert usw.) werde ich zukünftig mit Cinnamon arbeiten. Ich werde aber Manjaro trotz des (mittlerweile gelösten) Cups-Problems treu bleiben, da die Integration von Wine hier für mich einfacher ist und ich einige Win-Programme schlicht brauche (z. B. Helicon Focus, PDF-XChange usw.).
Jetzt muss ich erstmal meinen SSD-Salat ordnen und sortieren, denn sechs verschiedene Systeme sind mir auf Dauer zu viele ;-) Für solche Versuche kann ich einen Laufwerk-Wechselschacht sehr empfehlen.
Also, nochmals vielen Dank, ohne Eure Anregungen hätte ich die Lösung bestimmt nicht so schnell gefunden. Ich möchte mich am 15.01. gerne online bei Euch einklinken. Vielleicht sieht man sich ja ;-)
Euch allen auch Schöne Weihnachten (ich hab sie ja jetzt schon), einen guten Rutsch und das alles Corona-frei.
Viele Grüße aus Nordhessen, Benno
Am 23.12.20 um 12:05 schrieb Uwe Kleine-König:
Hallo Benno,
On 12/23/20 7:06 AM, btux wrote:
touch funktioniert auf allen Systemen auf dem NAS wie es soll.
Kannst du mal eine kleine Datei lokal auf Deiner Maschine anlegen und die dann mit cp -a auf das NAS kopieren und vom cp ein strace schicken, also etwa:
echo Hallo > somefile touch -m -t 202001020304 somefile strace -o /tmp/trace-cp -fv cp -a somefile /mnt/meinnas/tralala
und mir (ich schlage vor per PM und nicht auf die Liste wegen der Dateigröße) die Datei /tmp/trace-cp schicken?
Liebe Grüße Uwe
Hallo nochmal,
(die Details wiederhole ich jetzt mal nicht)
Wäre die Mail mit den Details auch noch verfügbar? Ich komme nicht zu den exakt gleichen Ergebnissen wie unten beschrieben bzw. habe einen anderen "Verdacht" und möchte das weiter vergleichen.
Mit freundlichen Grüßen
Manuel Ohnemus Dipl. Ing. (FH)
Konstruktion und Betriebsmittel Ohnemus Hauptstraße 72 D-77960 Seelbach Tel: +49 7823 961238-1 Fax: +49 7823 961238-4 manuel.ohnemus@kb-ohnemus.de https://www.kb-ohnemus.de
Am 10.05.21 um 11:43 schrieb ctux@dismail.de:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Hallo Manuel,
da ich derjenige war, der über viele Wochen nach einer Lösung gesucht habe biete ich mich mal als Lösungshelfer an;-)
Welche Details meinst Du bzw. viel interessanter: Welchen Verdacht hast Du?
Viele Grüße,
Benno
Am 10.05.21 um 15:41 schrieb Manuel Ohnemus:
Hallo nochmal,
(die Details wiederhole ich jetzt mal nicht)
Wäre die Mail mit den Details auch noch verfügbar? Ich komme nicht zu den exakt gleichen Ergebnissen wie unten beschrieben bzw. habe einen anderen "Verdacht" und möchte das weiter vergleichen.
Mit freundlichen Grüßen
Manuel Ohnemus Dipl. Ing. (FH)
Konstruktion und Betriebsmittel Ohnemus Hauptstraße 72 D-77960 Seelbach Tel: +49 7823 961238-1 Fax: +49 7823 961238-4 manuel.ohnemus@kb-ohnemus.de https://www.kb-ohnemus.de
Am 10.05.21 um 11:43 schrieb ctux@dismail.de:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
Hallo Benno, hallo Liste,
danke für Deine Rückmeldung.
Wo fange ich an: Ich hatte auch immer mal wieder das Thema mit mit geänderten mtimes nach Kopiervorgängen. Das hielt sich aber in Grenzen, deshalb hab ich mir weiter keine Gedanken gemacht und auch das Thema vor ein paar Monaten auf Flug nicht direkt verfolgt.
Ich habe mehrere Kubuntu-20.04 Clients, die per smbfs auch einen Centos bzw. Nethserver zugreifen. Die Laufwerke werden beim Login am Client per pam.mount / cifs unter /media eingebunden. Also gemountet, so wie man das auch über die fstab oder händisch per mount.cifs machen kann.
Beim hin-und herkopieren habe ich so keinerlei Probleme festgestellt, die mtimes bleiben bei Dateien erhalten. Etwas verunsichert, dass das so bei Kubuntu-21.04 nicht mehr gehen soll habe ich das mit einem Livesystem getestet, aber auch keine Probleme beim Kopieren festgestellt wenn die Laufwerke per cifs gemountet sind. Auch mit Dolphin unter 21.04 bleiben die mtimes erhalten.
Am Wochenende hatte ich dann Stress mit meiner Nextclound und musste meine kompletten Read-it-later-epubs neu nochladen. Normalerweise habe ich die nach Datum sortiert, jetzt hatten die alle das Datum vom Sonntag. Mist. Hochgeladen hatte ich sie per Nextcloud-Client. Diesen im Verdacht habe ich auf den Owncloud-Client gewechselt, damit blieben die mtimes erhalten. Leider war dies aber nicht der Grund, auch der Nextcloud-Client erhält die mtimes wie ich später getestet habe. Also auch mit Nextclound und den beiden Clients alles ok.
Was war der Fehler: Anstelle meine gesicherten Dateien per Dolphin von einem per cifs gemounteten Laufwerk in das Nextcloud-Client-Verzeichnis zu kopieren habe ich in Dolphin Netzwerk - Freigegebene Ordner - Sharename verwendet. Dabei wird die share nicht gemountet sondern direkt in Dolphin über smb://Sharename angesprochen. Das funktioniert auch nur mit KDE-Software die das Protokoll beherrscht. Jedenfalls werden die mtimes wenn man so kopiert oder verschiebt auf die aktuelle Zeit gesetzt.
Also kurz: Das KDE-Protokoll smb:// bzw. Freigegebene Ordner setzen mtime beim kopieren auf die aktuelle Zeit. Mountet man Sambashares richtig in ein Verzeichnis funktioniert alles auch unter Kubuntu 21.04 einwandfrei.
Mit freundlichen Grüßen
Manuel Ohnemus Dipl. Ing. (FH)
Konstruktion und Betriebsmittel Ohnemus Hauptstraße 72 D-77960 Seelbach Tel: +49 7823 961238-1 Fax: +49 7823 961238-4 manuel.ohnemus@kb-ohnemus.de https://www.kb-ohnemus.de
Am 10.05.21 um 16:37 schrieb btux:
Hallo Manuel,
da ich derjenige war, der über viele Wochen nach einer Lösung gesucht habe biete ich mich mal als Lösungshelfer an;-)
Welche Details meinst Du bzw. viel interessanter: Welchen Verdacht hast Du?
Viele Grüße,
Benno
Am 10.05.21 um 15:41 schrieb Manuel Ohnemus:
Hallo nochmal,
(die Details wiederhole ich jetzt mal nicht)
Wäre die Mail mit den Details auch noch verfügbar? Ich komme nicht zu den exakt gleichen Ergebnissen wie unten beschrieben bzw. habe einen anderen "Verdacht" und möchte das weiter vergleichen.
Mit freundlichen Grüßen
Manuel Ohnemus Dipl. Ing. (FH)
Konstruktion und Betriebsmittel Ohnemus Hauptstraße 72 D-77960 Seelbach Tel: +49 7823 961238-1 Fax: +49 7823 961238-4 manuel.ohnemus@kb-ohnemus.de https://www.kb-ohnemus.de
Am 10.05.21 um 11:43 schrieb ctux@dismail.de:
Der "Schuldige" ist KDE - hätte ich nie gedacht, aber ist so. Hier der Lösungsweg: Mint 20 basiert ebenso wie KDE-Neon auf Ubuntu 20.04. Beide verhalten sich beim Kopieren aufs NAS unterschiedlich (die Details wiederhole ich jetzt mal nicht) Durch die cp - Versuche von Uwe habe ich vermutet, dass die Zeitstempel-Wiederherstellung von dem Dateimanager erledigt wird. Den Problem-Systemen (Manjaro KDE, KDE-Neon, Kununtu 20.10) gemeinsam ist eine neuere Plasma/KDE-Version im Vergleich zu Kubuntu 20.04.
-
Andreas Delleske -
btux -
ctux＠dismail.de -
Manuel Ohnemus -
Uwe Kleine-König