SUMMARY When an archive has folders without timestamps, ark will use a timestamp of 01/01/1970 01:00. This can cause issues with other software (owncloud/nextcloud sync) as the extracted folder timestamp is considered invalid so the folder & contents do not get syncronised until a valid datetime is set. other software like 7zip and peazip do not do this, and appear to set the date to the time of file extraction. STEPS TO REPRODUCE 1. obtain a zip file that includes folders without a timestamp (https://www.thingiverse.com/thing:5027154/files is a specific example). 2. open/extract zip with Ark 3. note the 'Date' field is empty, or 1970 date of folder if extracted. EXPECTED RESULT honour either the valid date if it exists in the zip file, or have the folder timestamp use the datetime at the point of extraction. ADDITIONAL INFORMATION I guess there are a few train of thoughts to what the correct behaviour should be, but personally i don't believe 01/01/1970 would EVER be functionally correct, even if it is technically correct.
Same bugging behaviour on opensuse Leap 15.5. Needs fixing please !
*** Bug 467994 has been marked as a duplicate of this bug. ***
The linked site was possibly changed already. Clicking on "Download all files" gets me an archive with timestamps set to the time the archive was made. Do you still have such an archive which can be used as a reproducer? The zip format is messy, wanted to check whether the timestamp is actually missing (I'm not sure that can actually happen) or it's just set to 0. Without seeing more, I'm leaning towards the possibility that this may not be a (significant?) bug, and Bug #467994 had more info, especially with Bug #185209 being linked there which may be the ultimate desire. The empty "Date" field is still useful information. Let's theorize that the unix timestamp addition is missing. In that case I believe the ancient DOS-based timestamp which is not optional should be used, and according to https://stackoverflow.com/questions/3725662/what-is-the-earliest-timestamp-value-that-is-supported-in-zip-file-format , 1980-01-01 00:00 should be the earlier possible date with that. At least that's what's likely to be the technically correct approach, although I can't fault anyone for being happy enough with just unix timestamps working, not extending the already crazy domain of date and time handling with ancient DOS issues. Regarding the relevance of Bug #185209 , there's generally the problem that there's no invalid timestamp, the minimum (zero) value is just as valid as the maximum, even if some programs either can't handle part of the range (32-bit limitations, signed integer silliness, repurposing "unused" bit) or uses magic values for validity or error (minimum/zero and maximum typically). The DOS minimum of 1980-01-01 00:00 would likely work in your case, but pointing out that as the presence of that ancient timestamp is not optional, technically there's always a timestamp to be used.
I'd agree with your thoughts Pedro V. thanks for your input! looks like I've still got the original zip file i mentioned in the original post. Extracting it now results in another error ("there was an error while extracting....failed to read data for entry: folder/file_within_zip.stl"), but i'm not seeing 1970 dated files either. I re-downloading the zip from the provided link and do not experience the issue any more. In my case, that means the issue was specifically with how thingiverse were generating the zip and not reliably setting an expected date. The issue has been corrected and i'm no longer experiencing the 1970 date with either my old zip from 22-jan-23, or the one i've just downloaded tonight. fwiw, i'm now on Fedora40 KDEspin.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Created attachment 169676 [details] zip archive To unzip with the wrong time stamp, please use right clic and select : "extract archive here, detect subfolders"
Hi, thanks for your comments. I've posted an attachement containing de file created with the wrong timestamp. The difficulty with an archive not correctly dated is its lack of synchronization with Nextcloud. I must necessarily, once the archive has been decompressed, remove the file from the folder and immediately put it back (ctrl+z) which recreates a correct date allowing synchronization. the date crated by default is : jeudi 1 janvier 1970 00:00:00 CET Many thanks.
The bug still exists for me, each time i download documents from the electronic data solution of the ministry of justice (courtyards) in france : means, everyday !