Post

Replies

Boosts

Views

Activity

Reply to Ten FSKit issues found building a network file system module (all filed with minimal repros)
Hi, Just wanted to report an additional case: the volume-root invalidation failure also leaves stale positive name entries, not only negative ones. Filed as FB25243414, with a sysdiagnose taken while the stale entry was live. Setup: an FSKit FSUnaryFileSystem network volume on macOS 27.2, with negotiated caching. A directory dir exists at the top level of the share. On the client, ls <mount>/dir succeeds. On the server, dir is removed and a new directory with the same name is created. On the client, every access to <mount>/dir now fails with ESTALE. The kernel keeps resolving dir to the item for the deleted directory and never asks the module to look the name up again. To make the kernel look the name up again, the module would invalidate the parent directory. For the root, setCacheState(.invalidate) returns kIOReturnBadArgument, as in FB25077250. Only unmounting clears the entry. One level down, for <mount>/top/dir, the same replacement is picked up within a second. So the volume root is the only directory whose child names can't be refreshed, whether a name was missing or its item was replaced. Please allow invalidation of the volume root, or provide a way to invalidate a single name in a directory.
Topic: App & System Services SubTopic: Core OS Tags:
2w
Reply to Ten FSKit issues found building a network file system module (all filed with minimal repros)
Hi, Just wanted to report an additional case: the volume-root invalidation failure also leaves stale positive name entries, not only negative ones. Filed as FB25243414, with a sysdiagnose taken while the stale entry was live. Setup: an FSKit FSUnaryFileSystem network volume on macOS 27.2, with negotiated caching. A directory dir exists at the top level of the share. On the client, ls <mount>/dir succeeds. On the server, dir is removed and a new directory with the same name is created. On the client, every access to <mount>/dir now fails with ESTALE. The kernel keeps resolving dir to the item for the deleted directory and never asks the module to look the name up again. To make the kernel look the name up again, the module would invalidate the parent directory. For the root, setCacheState(.invalidate) returns kIOReturnBadArgument, as in FB25077250. Only unmounting clears the entry. One level down, for <mount>/top/dir, the same replacement is picked up within a second. So the volume root is the only directory whose child names can't be refreshed, whether a name was missing or its item was replaced. Please allow invalidation of the volume root, or provide a way to invalidate a single name in a directory.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
2w