wrong read/write datetime attributes

[TmTFx]

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.

[TmTFx]

In hrev 57406 x86_64 A file 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 file created in 28 Nov 2023 at 09:50:58 creates a time-attrib of 19/04/04 at 20:21

[TmTFx]

The bug is not about the screenshot app as this happens on other files too p.e.PDFs...

[Zardshard]

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.

[TmTFx]

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. )

[waddlesplash]

What's the time set inside the VM?

[augiedoggie]

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.

[augiedoggie]

viewing info of screenshot image

[TmTFx]

The time of the virtual machines were sincronized and correct, I'm using timezone of Italy-Rome GMT+1 The clip pasted explains clearly

[Zardshard]

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.

[Zardshard]

Side by side comparison of what the "Get info" window and Tracker say the creation time is

[waddlesplash]

Those are two different fields. One is the creation time, the other is an attribute indicating the time the thumbnail was last updated.

[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?

[augiedoggie]

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.

[Zardshard]

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

[waddlesplash]

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" *

[waddlesplash]

No further feedback; closing as presumed fixed.