Opened 12 months ago
Closed 9 months ago
#18691 closed bug (fixed)
wrong read/write datetime attributes
Reported by: | TmTFx | Owned by: | nobody |
---|---|---|---|
Priority: | critical | Milestone: | R1/beta5 |
Component: | Applications/Tracker | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This differs from x86 and x64 Haikus, but in both architectures the generation and the value read by Tracker is wrong. p.e. Also the generation of the creationtime attribute of a screenshot is wrong and the generated value differs from x86 and x64.
Attachments (2)
Change History (18)
comment:2 by , 12 months ago
The bug is not about the screenshot app as this happens on other files too p.e.PDFs...
comment:3 by , 12 months ago
Bad news: I'm not able to reproduce it. I tested
- hrev 57377 x86_64
- hrev 57419 x86_64
- hrev 56578 x86
I took a screenshot by typing screenshot
in the command line. Then, I used Tracker to view the creation date. All of the creation dates were in November 2023, as expected.
comment:4 by , 12 months ago
Oh boy, this is odd indeed, I tried myself on a barebone Haiku machine and it works right as you said... It seems it happens only on my virtual Haikus (under libvirt on OpenSUSE and Fedora), the first oddity is that pressing stamp key (which launces screenshot app) creates an image with attributes, where as you said and as I see in my barebone machine this is not happening, the second oddity is that the the value read in virtual machines is wrong, I should compare it in my barebone machine before adding more details. Sadly I cannot do it right now. If you have a pdf with a creation and modification time attribute (beware, not the filesystem datetime stamp, the BFS attribute you can list, read, remove etc. with "listattr", "catattr" etc. )
comment:6 by , 12 months ago
I can see some problems with the media attributes in my x86_64 nightly vmware VM and the time is set correctly. I haven't tried it bare metal.
comment:7 by , 12 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Priority: | normal → critical |
comment:8 by , 12 months ago
The time of the virtual machines were sincronized and correct, I'm using timezone of Italy-Rome GMT+1 The clip pasted explains clearly
comment:9 by , 12 months ago
I managed to reproduce it! If I use the "Get info" window, I get 12/19/63, whereas Tracker instead correctly displays Nov 28, 2023.
by , 12 months ago
Attachment: | side_by_side_comparison.png added |
---|
Side by side comparison of what the "Get info" window and Tracker say the creation time is
comment:10 by , 12 months ago
Those are two different fields. One is the creation time, the other is an attribute indicating the time the thumbnail was last updated.
follow-up: 12 comment:11 by , 12 months ago
So in that case, this ticket is not talking about the "created" column in Tracker, just the "Media:Thumbnail:CreationTime" attribute and other such attributes of type B_TIME_TYPE
not being read or written correctly?
comment:12 by , 12 months ago
Replying to Zardshard:
So in that case, this ticket is not talking about the "created" column in Tracker, just the "Media:Thumbnail:CreationTime" attribute and other such attributes of type
B_TIME_TYPE
not being read or written correctly?
I think it's probably just an improperly set time variable hiding in the Tracker thumbnail creation functions but I haven't looked into it.
comment:13 by , 12 months ago
I think you're right. Tracker stores the results of real_time_clock_usecs()
, which returns the type bigtime_t
, into an attribute of type B_TIME_TYPE
, which is supposed to store data of type time_t
.
Notably, bigtime_t stores microseconds while time_t usually (according to cppreference) stores seconds!
Code where time is stored in attribute in Tracker: https://git.haiku-os.org/haiku/tree/src/kits/tracker/Thumbnails.cpp#n227
comment:14 by , 12 months ago
Component: | - General → Applications/Tracker |
---|
comment:15 by , 12 months ago
Should be fixed in hrev57428. Note that existing file thumbnails may not be updated if the timestamps read as being in the future. You can remove such invalid attributes for all files in a folder at once like this
rmattr "Media:Thumbnail:CreationTime" *
comment:16 by , 9 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
No further feedback; closing as presumed fixed.
In hrev 57406 x86_64 A screenshot created in 28 Nov 2023 at 09:47:58 creates a time-attrib of 20/12/63 at 01:00
In hrev 57380 x86 A screenshot created in 28 Nov 2023 at 09:50:58 creates a time-attrib of 19/04/04 at 20:21