https://bugs.kde.org/show_bug.cgi?id=523078
Bug ID: 523078
Summary: Received file gets mtime = 0 when Android sender
reports lastModified: 0
Classification: Applications
Product: kdeconnect
Version First 26.04.3
Reported In:
Platform: EndeavourOS
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: desktop-application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
DESCRIPTION
Files received from an Android device get mtime = 0 (1970-01-01) when the
file is shared from Google Photos. The desktop applies the received
lastModified value verbatim without checking it for plausibility.
STEPS TO REPRODUCE
1. On Android, open an image in Google Photos and share it to the desktop
via KDE Connect.
2. On the desktop, run `stat` on the received file in the incoming folder.
3. Share the identical image again, this time from a SAF-based file manager
(tested with FX File Manager), and `stat` that file too.
OBSERVED RESULT
Via Google Photos, Modify is exactly epoch 0. Birth is correct.
Modify: 1970-01-01 02:00:00.000000000 +0200
Birth: 2026-07-15 09:07:28.989112850 +0300
Via FX File Manager, Modify is a plausible current timestamp (roughly the
transfer time) rather than 0:
Modify: 2026-07-15 09:26:03.583000000 +0300
Birth: 2026-07-15 09:26:03.626480437 +0300
Both files are 159693 bytes, so the payload is identical and only the
metadata differs. In Dolphin the epoch-0 files sort to the bottom of any
date-ordered listing.
EXPECTED RESULT
A lastModified of 0 should be treated as absent/unknown, and the mtime left
at write time.
SOFTWARE/OS VERSIONS
Operating System EndeavourOS
KDE Plasma Version: 6.7.2
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
KDE Connect (desktop): 26.04.3
KDE Connect (Android): 1.35.9
ADDITIONAL INFORMATION
Presumably Google Photos' content provider does not expose a modification
date, so the Android app has nothing to read and sends lastModified: 0. The
sending app arguably can't do better here, but the receiving side applying a
zero timestamp verbatim seems wrong regardless of sender — 0 is not a
plausible mtime for a file anyone shares interactively.
Possibly related: bug 503168 (iOS sender, creation/modification fields
swapped). Different platform and different failure mode, but both stem from
the desktop trusting sender-supplied timestamps unconditionally.
--
You are receiving this mail because:
You are watching all bug changes.
