Network volume and file identity

For network volumes where volumeUUIDStringKey is nil, is there any other stable volume/share identifier suitable for namespacing file IDs? More generally, what should I use as the volume identity component when persisting file identifiers for network files?

If volumeSupportsPersistentIDsKey == true on a network volume, can fileIdentifierKey / systemFileNumber be expected to survive unmount/remount, reconnect, and server restart?

Does fileIdentifierKey on network volumes represent the same kind of filesystem identity as it does on local/removable volumes?

Thanks!

Answered by Engineer in 891194022

It is annoying that the SMB protocol does have some support for server and share IDs, but no implementation seems to fill them in with persistent IDs. I have found no way to uniquely identify a server/share after it has been unmounted for all SMB server implementations. So, using a best effort method is your only answer for all of us.

For SMB, the answer is maybe.  If the server supports the AAPL Create Context and also supports ResolveID and supports unique File IDs (ie non zero file ids in various SMB replies), then the attribute VOL_CAP_FMT_PERSISTENTOBJECTIDS is returned and the IDs will be persistent across unmount/mount, etc. Servers that support this are Apple SMB File Servers and other SMB servers may optionally support this if they wish to.

If VOL_CAP_FMT_PERSISTENTOBJECTIDS is not set, then all IDs from SMB are only guaranteed to be persistent until the unmount. The IDs should survive a reconnect.

Thanks, that clarifies the SMB file ID side.

For SMB volumes that do set VOL_CAP_FMT_PERSISTENTOBJECTIDS, is there any stable volume/share identifier exposed to clients that should be used to namespace those persistent file IDs when volumeUUIDStringKey is nil?

Or should I use their own best-effort namespace such as the mounted volume URL, remount URL, or bookmark/root path?

Accepted Answer

It is annoying that the SMB protocol does have some support for server and share IDs, but no implementation seems to fill them in with persistent IDs. I have found no way to uniquely identify a server/share after it has been unmounted for all SMB server implementations. So, using a best effort method is your only answer for all of us.

Network volume and file identity
 
 
Q