Bug 356651 - Moving files onto a smb network share sets the files' access/modify times to the current date/time.
Summary: Moving files onto a smb network share sets the files' access/modify times to ...
Status: RESOLVED FIXED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: Samba (show other bugs)
Version: unspecified
Platform: Other Linux
: VHI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 79937 365901 417306 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-12-14 07:11 UTC by jamespharvey20
Modified: 2020-03-03 19:32 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 19.12.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jamespharvey20 2015-12-14 07:11:58 UTC
Files moved from the local machine onto a smb network share use the current date/time to set the file's access and modify time, rather than using the times the file started with.  Mounting a smb network share through fstab and using mv in a terminal keeps the file's original access and modify time.

Reproducible: Always

Steps to Reproduce:
1. Open two Dolphin windows, one in a local btrfs directory, another on a smb share accessed by going to Network and using Add Network Folder, then browsing to that new network folder underNetwork.
2. Select a file(s) in a local btrfs directory, and drag onto the dolphin window showing the smb share.
3. Choose "Move here" when asked.

Actual Results:  
The file on the smb network share shows the current date/time as the access and modify times.

Expected Results:  
The file on the smb network share should show the file's original access and modify times, as the mv command does when moving to a smb mount.

Up to date arch.  Note I am NOT talking about the change time, just access/modify.  I could expect this behavior if copying, because there's no way to give an equivalent to cp's "--preserve" option.  Moving from a local directory to a local directory, in separate dolphin windows, leaves the times alone, working as I'd expect.  Moving from the smb share to a local directory sets the modify time to the current date/time, but sets a corrupt access time - I'm getting "2106-02-07 06:28:15.000000000 +0000".  Yes, 2106 is not a typo.  And, no, 06:28:15 is not even the time of day it should be, even ignoring the date.
Comment 1 Frank Reininghaus 2015-12-23 14:10:05 UTC
Thanks for the bug report. This might be a problem either in the smb kioslave or in the KIO framework.
Comment 2 Nate Graham 2017-08-18 16:01:20 UTC
*** Bug 365901 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2018-04-24 21:49:25 UTC
*** Bug 79937 has been marked as a duplicate of this bug. ***
Comment 5 Harald Sitter 2020-02-12 15:32:37 UTC
I'm pretty sure we always change the atime for local<->remote transfers, even when you move. You'll move across a boundary (i.e. the network) so we do technically and practically have to read the file to move it to the new destination. That seems entirely expected and intentional to me.

The mtime is indeed bugged though.
Comment 6 Nate Graham 2020-02-12 16:37:05 UTC
Patch: https://phabricator.kde.org/D27351
Comment 7 Harald Sitter 2020-02-13 11:27:24 UTC
Git commit aaedd983729f85129a91d861e1e4c2cc6ad084cb by Harald Sitter.
Committed on 13/02/2020 at 11:17.
Pushed by sitter into branch 'master'.

smb: call smb_cutime on the correct url to actually set mtime properly

Summary:
since the introduction of partial resume dstUrl would can be the .part url
whereas dstOrigUrl is the final destination url.

i.e.
we called smbc_utime on smb://foo/bar.part rather than smb://foo/bar
FIXED-IN: 19.12.3

Test Plan: moving file to smb retains mtime

Reviewers: ngraham

Reviewed By: ngraham

Subscribers: kde-frameworks-devel, kfm-devel

Tags: #dolphin, #frameworks

Differential Revision: https://phabricator.kde.org/D27351

M  +1    -1    smb/kio_smb_dir.cpp

https://commits.kde.org/kio-extras/aaedd983729f85129a91d861e1e4c2cc6ad084cb
Comment 8 Patrick Silva 2020-03-03 19:32:18 UTC
*** Bug 417306 has been marked as a duplicate of this bug. ***