retain atime properly

Authored by sitter on Feb 12 2020, 3:39 PM.



this was broken since forever I guess. when the .part resume tech was
added it didn't correctly retain the access time. it was trying to
get the atime of 'file', but 'file' when resuming refers to the .part which
was deleted prior to the mtime adjustment so the QFileInfo(file).lastRead
would produce an Invalid QDateTime which then results in us setting random
nonesense as access time on the file.
instead simply use dstFile. it is the path of the actual final destination
file of which the atime is actually the one we want to preserve here
considering we've literally just accessed that file by copying it ^^

BUG: 410624
FIXED-IN: 19.12.3

Test Plan

copy file form smb to local has sound atime

Diff Detail

R320 KIO Extras
No Linters Available
No Unit Test Coverage
Build Status
Buildable 22407
Build 22425: arc lint + arc unit
sitter created this revision.Feb 12 2020, 3:39 PM
Restricted Application added projects: Dolphin, Frameworks. · View Herald TranscriptFeb 12 2020, 3:39 PM
Restricted Application added subscribers: kfm-devel, kde-frameworks-devel. · View Herald Transcript
sitter requested review of this revision.Feb 12 2020, 3:39 PM
meven accepted this revision.Feb 12 2020, 4:13 PM
This revision is now accepted and ready to land.Feb 12 2020, 4:13 PM

So when I copy a file from my samba share to my desktop, the accessed time of the copied file on my machine should match the accessed time of the version on the server? If so, it doesn't seem to work for me; the accessed time is reset to the time when the file was copied.

No, the access time is always the current time, the modified time should not change.

The modified time changes too. Am I testing this right?

I think I tried with moving. Currently not at home to check.

Oh I'm sorry, I thought this was the other time diff.

In this case before the accessed time before the patch was flat out garbage note the year 2106

This revision was automatically updated to reflect the committed changes.