| Summary: | ark creates folders with 01/01/1970 timestamp | ||
|---|---|---|---|
| Product: | [Applications] ark | Reporter: | Tim D <veehexx> |
| Component: | general | Assignee: | Elvis Angelaccio <elvis.angelaccio> |
| Status: | NEEDSINFO WAITINGFORINFO | ||
| Severity: | normal | CC: | aacid, fc, gab, rthomsen6, voidpointertonull+bugskdeorg |
| Priority: | NOR | ||
| Version: | 22.12.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Tim D
2023-01-22 08:02:00 UTC
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! |