https://bugs.kde.org/show_bug.cgi?id=467994
Bug ID: 467994
Summary: Ark extracted files from dolphin context menu wrong
modification time breaks Nextcloud sync
Classification: Applications
Product: ark
Version: 22.12.1
Platform: Debian unstable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: elvis.angelac...@kde.org
Reporter: g...@diniciacci.org
CC: aa...@kde.org, rthoms...@gmail.com
Target Milestone: ---
This is related to Bug 185209
This has become an issue for all our office and I think I have a way to
reproduce, even if it might not be super generic, it is reliable here.
Steps to reproduce:
pre) Create a directory with a subdirectory with pictures from a camera inside.
Those pictures usually have a creation date set but not a modification date
set. Most of the cameras create files like that (i.e probably from FAT32 fs or
related). 0) Upload it to OneDrive or other captive location.
1) Visit (evil) OneDrive and download the above directory from there.
2) The directory will be downloaded as a zip file.
3) Use Dolphin and visit the location where you downloaded the zip file.
4) Right click on the zip file and select "Extract">"Extract archive here".
5) Check the modification dates of files. It will be set to 01/01/1970 at 00:00
(zero seconds from the Unix epoch).
5bis) The same happens if one uses $ ark -d <directory> modification time
is set to zero.
OBSERVED RESULT
The modification date set is invalid, there is no way to set it globally, see
bug 185209.
EXPECTED RESULT
If date is invalid (i.e. modification date is before creation date, or just set
to zero) then ark should set modification date the same as creation date.
Workaround:
If instead of using the context menu "Extract">"Extract archive here" one opens
Ark dialog and drag and drops the root zipped directory, then the modification
time is correctly set to current time.
Notice that "Extract archive here" is behaving differently, by default, from
drag and drop (and this is per-se a glitch to fix IMHO).
USE CASE
This introduces a quite relevant problem. Any local sync service that checks
and uses modification time of files to track them will whine at the fast that
modification time is set before creation time. In particular Nextcloud will
refuse to sync the aforementioned extracted files remotely considering the
modification time invalid. This basically breaks Nexcloud sync. IMHO this makes
this small bug quite actual.
I.E.
Directories extracted using the "Extract archive here" context menu option will
fail to sync to Nextcloud.
This will happen every time a directory if recovered from an online storage
service (in particular in OneDrive, but should happen also in Wetransfer and
alike that zip directories on dowload)
SOFTWARE/OS VERSIONS
Windows: not even in my last day
macOS: not even if i lose half of my brain
Linux/KDE Plasma: Linux debian 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.12-1 (2023-02-15) x86_64
KDE Plasma Version: 5.27.0
KDE Framework Version: 5.103.0
Qt Version: 5.15.8
ADDITIONAL INFORMATION
Local filesystem Ext4
I do not like MS
Our customers are using OneDrive, so we can't avoid interacting with,
eventually and/or intentionally, malformed zip files or located of buggy FS
that set modification date to the future.
--
You are receiving this mail because:
You are watching all bug changes.
