Bug 374420

Forgot to mention, this works fine with kioclient instead of kioclient5, so it's a regression.

I'm seeing 2106-02-07 07:28 pop up a lot lately, after switching Konqueror and KDE PIM to KDE5. For example, files downloaded from Konqueror and some entries in my Akregator feeds.

I'm using KDE Frameworks 5.38.0 from openSUSE.

These are actually two separate issues.

1) The http slave does indeed not set a modification time in the UDSEntry, as a result the mtime is set to -1 in the CopyJob. This is exactly how it was in KDE4 however.
The regression now is that CopyJob::copyNextFile() doesn't check for -1 anymore and sets the modification time for the FileCopyJob unconditionally (to -1 in this case). The check got lost in the port to Qt5.

2) This is actually a problem in the ftp slave. It uses this code to set the destination file's mtime:
                struct utimbuf utbuf;
                utbuf.actime = sPartInfo.lastRead().toTime_t(); // access time, unchanged
                utbuf.modtime = dt.toTime_t(); // modification time
                ::utime(QFile::encodeName(sCopyFile).constData(), &utbuf);
But sPartInfo points to a .part file of a previously aborted copy, and may not exist in the first place (in which case sPartInfo.lastRead().toTime_t() apparently yields -1).

I have fixes for both problems, and will propose a fix soon.

PS:
(In reply to Maarten ter Huurne from comment #2)
> I'm seeing 2106-02-07 07:28 pop up a lot lately, after switching Konqueror
> and KDE PIM to KDE5. For example, files downloaded from Konqueror and some
> entries in my Akregator feeds.

The Akregator feeds problem is likely not related to this I think.

That's rather a problem with parsing dates in the feed's data or handling invalid data, but there are other bug reports about that anyway...

*** Bug 405793 has been marked as a duplicate of this bug. ***

(In reply to Wolfgang Bauer from comment #3)
> I have fixes for both problems, and will propose a fix soon.

Wolfgang, did you submit those fixes?

(In reply to Elvis Angelaccio from comment #6)
> (In reply to Wolfgang Bauer from comment #3)
> > I have fixes for both problems, and will propose a fix soon.
> 
> Wolfgang, did you submit those fixes?

Not yet, sorry. I got distracted by other things, and even accidentally deleted my existing patch somehow... :-/

But I hope to get round to doing it again in the next days.

Git commit 5e791ef216c230efc15b853c08b21d41eca65e0c by Wolfgang Bauer.
Committed on 21/06/2019 at 13:30.
Pushed by wbauer into branch 'master'.

[copyjob] Only set modification time if the kio-slave provided it

If the slave didn't pass a modification time (e.g. the http slave
doesn't), it was set to -1, resulting in setting a wrong modification
time for the destination file in copyNextFile() later on because that
case wasn't checked.

So only set info.mtime when the slave actually provided a value.

There's no need for further checks later in copyNextFile() (where
FileCopyJob::setModificationTime() is called) because FileCopyJob checks
for validity anyway.
FIXED-IN: 5.60.0
Differential Revision: https://phabricator.kde.org/D21955

M  +4    -1    src/core/copyjob.cpp

https://commits.kde.org/kio/5e791ef216c230efc15b853c08b21d41eca65e0c

PS: I proposed a fix for the ftp slave problem as well:
https://phabricator.kde.org/D21952

Git commit f9c2dfb6e8df7491dff5077724cc16bc1679f768 by Wolfgang Bauer.
Committed on 03/07/2019 at 20:13.
Pushed by wbauer into branch 'master'.

[ftp] Fix wrong access time in Ftp::ftpCopyGet()

sPartInfo refers to the .part file which might not exist in the first
place, resulting in a wrong/invalid access time.
To avoid this, take the access time from the actual destination file
instead.

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

M  +2    -1    src/ioslaves/ftp/ftp.cpp

https://commits.kde.org/kio/f9c2dfb6e8df7491dff5077724cc16bc1679f768

*** Bug 389584 has been marked as a duplicate of this bug. ***

*** Bug 396932 has been marked as a duplicate of this bug. ***