Invalid st_ino values in Endpoint Security events for FAT16 and ExFAT

Hello everybody!

I'm working on EndpointSequirity client and noticed that when I copy a file to an external flash card with FAT16 or exFAT file systems the ES_EVENT_TYPE_NOTIFY_CREATE event and the very first ES_EVENT_TYPE_NOTIFY_WRITE one have some fake value for st_ino field in their stat structures. For FAT it is 999999999, and for exFAT it is 1. Starting from the second write notification the stat structure gets a real inode number. It does not happen for APFS file system.

Could someone please tell me this known behavior, and point me to a place where it is documented? For which other file systems can this also happen?

Thanks in advance, Aleksandr Skobelev

Answered by DTS Engineer in 695738022

The concept of an inode number is very Unix-y, and it doesn’t always map well to file systems with a non-Unix heritage [1]. File systems that don’t have this concept have to synthesise it in some way, and it seems that the process used by the file systems you mentioned isn’t quite working for an ES client. You should file a bug about this, for us either to fix the problem or, if that’s not possible, document it.

Please post your bug number, just for the record.

Share and Enjoy

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

[1] Indeed, we were very lucky when we brought up Mac OS X that HFS Plus’s CNID, which it inherited from HFS, which dates all the way back to 1985, was a relative good match for the inode number.

Accepted Answer

The concept of an inode number is very Unix-y, and it doesn’t always map well to file systems with a non-Unix heritage [1]. File systems that don’t have this concept have to synthesise it in some way, and it seems that the process used by the file systems you mentioned isn’t quite working for an ES client. You should file a bug about this, for us either to fix the problem or, if that’s not possible, document it.

Please post your bug number, just for the record.

Share and Enjoy

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

[1] Indeed, we were very lucky when we brought up Mac OS X that HFS Plus’s CNID, which it inherited from HFS, which dates all the way back to 1985, was a relative good match for the inode number.

Invalid st_ino values in Endpoint Security events for FAT16 and ExFAT
 
 
Q