https://bugs.kde.org/show_bug.cgi?id=458562
Riccardo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |CONFIRMED Platform|Ubuntu |Kubuntu Ever confirmed|0 |1 CC| |[email protected] --- Comment #4 from Riccardo <[email protected]> --- I can confirm this on current versions. I noticed it when copying photos from an SD card to my NAS with Dolphin. Client: Kubuntu 26.04 LTS, KDE Plasma 6.6.6, KDE Frameworks 6.24.0, Qt 6.10.2, Dolphin 25.12.3, kernel 7.0.0-38-generic, Wayland. Server: Synology DS416, DSM 7.3.2-86009 Update 4. The share is mounted via fstab: //192.168.x.y/home /mnt/nas/home cifs credentials=...,vers=3.1.1,uid=1000,gid=1000,iocharset=utf8,noauto,x-systemd.automount,x-systemd.idle-timeout=300,_netdev 0 0 (effective mount options also include cache=strict) Test: a 30 MB local file with mtime set to 2020-01-01 12:00, copied to the mounted share: - Dolphin (copy/paste into /mnt/nas/...): mtime = time of the copy - cp -p: mtime = time of the copy (exit code 0, no error shown) - rsync -t: mtime preserved - touch -d on the file already on the share: mtime set correctly So the server does accept setting the mtime, but the value seems to be overwritten when the destination file is closed, if the mtime was set while the file was still open (as cp -p does). rsync sets the mtime after closing the file, and that works; FreeFileSync, mentioned in the original report, probably behaves the same way. Would it be possible for KIO to set the modification time after the destination file has been closed, at least on network file systems such as CIFS? -- You are receiving this mail because: You are watching all bug changes.
