Difference between vfsStruct.f_fsid and fstat.st_ino ?

Anyone know of relevant documentation that captures the difference between vfsStruct.f_fsid and fstat.st_ino?

There things aren’t related at all. st_ino is the inode number, that is, a unique identifier for the file. In contrast, f_fsid is a unique identifier for the file system, that is, the volume on which the file resides. The getattrlist man page makes this clear:

• ATTR_CMN_FSID — An fsid_t structure containing the file system identifier for the volume on which the file system object resides. Equivalent to the f_fsid field of the statfs structure returned by statfs.

• ATTR_CMN_FILEID — A u_int64_t that uniquely identifies the file system object within its mounted volume. Equivalent to st_ino field of the stat structure returned by stat.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks @eskimo.

Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented ?

Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented?

I don’t understand this question. You’re using a bunch of words that don’t map to any technology that I recognise. Can you post a link to the user-level documentation for the feature you’re interested in?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Greetings,

It turns out that feature-info I was looking for is about an APFS feature called Copy-On-Write-Clones . I was able to view documentation on it so I am good for now.

For Finder copy-operations, with destination being the same volume, APFS seems to be creating the new file with different meta-data but the file shares the same data-content as the original. During my tests, I found that copying a 1GB file on the same volume via Finder did not decrease the available space on the Volume by 1GB. What was cool was that if I appended to the new File, then the disk-available-space gets decreased by only the bytes that were appened to the new File. So, the Sharing of data-content/blocks continues even post the edit. I ran some more tests with Finder and /bin/cp command. 1). As expected, the same Finder copy operation on HFS+ volumes has a different behavior than Finder copies on APFS. 2). However when comparing Finder-based-copy operation with cp-command copy operation on MacOS-APFS, the behavior strangely differs when it comes to CopyOnWriteClones. Not sure why, but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig; Finder based copies on the other hand are exibiting the space-saving behavior.

Thanks,

Vikram.S.Warraich.

Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy. cp -c : copy files using clonefile(2)

Also, The f_fsid related observations/content in my first comment on this post is not correct. Thanks @eskimo for correcting me regarding that st_ino and f_fsid are not related.

but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig

Yes.

cp is a BSD-level tool, and BSD traditionally doesn’t have a ‘copy file’ API. Thus, cp opens both files and copies the data chunk-by-chunk, which means it won’t benefit from APFS’s CoW support.

Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy. cp -c

Yep. This isn’t the default because folks might depend on the subtle semantics of cp.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"