Spotlight: Revert some changes to timestamps

[NJRoadfan]

No description provided.

[augmentcode]

🤖 Augment PR Summary

Summary: This PR rolls back Spotlight timestamp updates by removing the code path that applied kMDItemLastUsedDate to filesystem timestamps.

Changes:

• Drops the kMDItemLastUsedDate handling in sl_rpc_storeAttributesForOIDArray(), leaving only the kMDItemFSContentChangeDate-based update.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. No suggestions at this time.

Comment augment review to trigger a new review at any time.

[NJRoadfan]

Unless a stat() call is made to retrieve a file's mtime beforehand, you can't update just the atime with utime(), hence the error with the mtime being reset everytime the client sends kMDItemLastUsedDate back to the server. We don't want to needlessly trigger a stat() call each time a file is accessed, so this revert will have to do for now. Note that some OSes, such as Linux mount their filesystems with the relatime option which won't update the atime of a file on each actual access to lower overhead, so the "Last Accessed" time in Finder won't always be accurate.

[rdmark]

@NJRoadfan can you take a look at this PR that might address the issue without reverting -- #2897

this resolves the issue I was seeing (host is Linux, client is macOS)

do you see any reason why calling utimensat() every time here would be a bad idea?

[NJRoadfan]

It should be fine for this use. Is utimensat() available on all platforms? I'm seeing references that older macOS (<10.13) don't support it and the call isn't used anywhere else in the Netatalk code base.

[rdmark]

utimensat is POSIX 1-2008 and contemporaneous with other at-functions that we rely on

my second internalized justification was that the Spotlight stack (Localsearch or recent Tracker etc) is unlikely to be usable on older OSes anyways, so they won't be compiling this code

that said a capability check for utimensat with a portable fallback is definitely the more prudent solution