> $ kioclient5 copy "http://kde.org" /tmp/file > $ LANG=C stat /tmp/file > File: '/tmp/file' > Size: 27932 Blocks: 56 IO Block: 4096 regular file > Device: 26h/38d Inode: 42361390 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 1000/ fabian) Gid: ( 100/ users) > Access: 2017-01-01 14:25:07.000000000 +0100 > Modify: 2106-02-07 07:28:15.000000000 +0100 > Change: 2017-01-01 14:25:08.032913190 +0100 > Birth: - The mtime is wrong here. > $ kioclient5 copy "ftp://upload.kde.org/README" /tmp/file > $ stat /tmp/file > File: '/tmp/file' > Size: 594 Blocks: 8 IO Block: 4096 regular file > Device: 26h/38d Inode: 42366998 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 1000/ fabian) Gid: ( 100/ users) > Access: 2106-02-07 07:28:15.000000000 +0100 > Modify: 2013-04-27 00:00:00.000000000 +0200 > Change: 2017-01-01 14:27:14.582228552 +0100 > Birth: - Same for there access date here. Those timestamps are all 0xFFFFFFFF, which is invalid. I've also seen "4442051-11-19 02:36:00" as access date once, so it may be the result of an uninitialized read.
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. ***