Is inode invalidation currently supported?

I cannot find anywhere in the documentation how to invalidate an FSItem.

What are you actually trying to do here?

It seems to be cached indefinitely or am I missing something?

In terms of caching, reclaimItem is the point where you'd typically drop all of your references to the FSItem, since that's the point where the larger system no longer has any reference to the object.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

What I’m actually trying to do is notify FSKit that a file’s contents or attributes have changed.

I couldn’t find any API in the docs to invalidate or refresh an existing FSItem. reclaimItem makes sense as the point where I drop my references when the system is finished with the object, but it doesn’t seem like the right mechanism for “this file changed; please refresh any cached state.”

Is there an intended way to signal that kind of change to FSKit, or is there no explicit invalidation mechanism?

What I’m actually trying to do is notify FSKit that a file’s contents or attributes have changed.

...

Is there an intended way to signal that kind of change to FSKit, or is there no explicit invalidation mechanism?

Got it. So, the answer here is that this currently doesn't exist. This kind of functionality is only relevant to network/shared file systems [1], which FSKit doesn't currently have full support for.

On that note, if you have a moment, I'd appreciate you filing a bug on this describing exactly what you need/want from this API and then posting the bug number back here. This is an area FSKit is very interested in supporting, so they're actively interested in feedback about how that API should work.

[1] In a local file system, all changes originate directly in the VFS layer, so there isn't any reason for the file system to "notify" the VFS layer.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I just checked the macos 27 beta, it seems like the invalidation mechanism has been built into the lifs/fskit