Bug 396932

Summary:	Copy Browser URL Causes Incorrect File Timestamp
Product:	[Frameworks and Libraries] frameworks-kio	Reporter:	vindicator <nroycea+kde>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED DUPLICATE
Severity:	minor	CC:	chinmoyrp65, elvis.angelaccio, kde, kdelibs-bugs, mail, wbauer1
Priority:	NOR
Version:	5.48.0
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:

Description vindicator 2018-07-28 15:47:51 UTC

1) Using google-chrome, go to any website.
2) Drag the "View Site Information" (located at at the beginning of the address bar) to a path in Dolphin
3) Click "Copy"

Note the date/timestamp. Mine shows the modified date/time to be "2/7/06 12:28 AM" for everything I copied.
When I "ls -l" that file in a terminal, I find the year isn't even 2006, but rather 2106!!!

The timestamp seems so random, but I figure there's some meaning behind it.

I am using "Copy" instead of "Link" so I have the content of the page for future reference in case that page gets removed or the content changes.

"Link" DOES get the correct timestamp.

Comment 1 Julian Steinmann 2018-07-28 16:26:22 UTC

Thanks for reporting this bug! The behavior you noticed is funny, but easy to explain: if we convert the time and date to the corresponding epoch timestamp, we get something near 4294967296 as a result, which is the maximal number that can fit in an unsigned C++ integer. So this is obviously not the expected behavior because Dolphin does not pick up the time correctly, but makes sense as Dolphin seems to fall back to the maximal possible value (which then leads to this date in the distant future).

Comment 2 Kai Uwe Broulik 2018-07-30 08:11:37 UTC

The same happens when dragging an image from the browser to the desktop and choosing "Copy". I tried to investigate it once but failed to find a proper fix, the issue lies in KIO copy job or drop job iirc.

(Btw 2106 is "-1" timestamp which it uses internally for "unknown date")

Comment 3 Chinmoy Ranjan Pradhan 2019-01-25 08:56:18 UTC

I think the issue is with remote protocol's stat() method which should set UDS_MODIFICATION_TIME. In case of http it doesn't so CopyJob ends up setting it as -1.

Comment 4 Wolfgang Bauer 2020-07-01 09:51:53 UTC

Probably related to bug#374420.

Does it still happen with KDE Frameworks 5 versions newer than 5.60?

Comment 5 Wolfgang Bauer 2021-01-15 09:53:22 UTC

No response, so let's assume it was the same problem.

I cannot reproduce it here with the latest versions at least.

*** This bug has been marked as a duplicate of bug 374420 ***