Hello,
es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field.
What is the best way to define file system type? Can I use 'f_type' or 'f_fstypename'? If so, are there any constants in header files which can be used?
Thank you for your help!
es_event_mount_t includes statfs structure. This structure has the field 'f_type' which defines type of filesystem. However, man page says nothing about possible values of this field.
Yes, and the short summary is that the value of "f_type" isn't something that will be all that useful to you (which is what it isn't defined).
What is the best way to define file system type? Can I use 'f_type'
No.
or 'f_fstypename'?
What are you actually trying to do? If you're you're purely collecting a value for display/informational purposes, then sure, you can copy that value. However:
If so, are there any constants in header files which can be used?
...if you're trying to base programmatic decisions on "file system type", well, that doesn't really work. There are there are a two critical issues with that approach:
-
The value isn't stable. You can add new files systems to the system, which means the fields value isn't predictable.
-
The characteristics of a given file system are FAR more variable than most developers expect. As the most direct example, smb shares typically "present" themselves as having the same capabilities (or less) of their parent file system, which means they can basically present as the same configuration "range" as basic FAT all the way to case sensitive APFS.
The preferred approach here is to look for the capabilities you're interested in, typically through "getattrlist". That won't be an option prior to mount, but it's the better approach if you're trying to gather information post-mount.
Finally, returning to this point:
es_event_mount_t includes statfs structure.
My recommendation is that you use DiskArbitration as your primary mechanism for blocking mounts. This post and this post have more details about why that's the case, but the quick summary is:
-
You'll have access to more information than ES provides.
-
You won't have the same level of time pressure that ES does.
-
The system "expects" DiskArb to block mounts, so it handles those failures relatively gracefully.
You'll still use es_event_mount_t as the "final" protection system, but it's role will be to immediately approve mounts you've already preflighted with DiskArb and block edge cases where DiskArb is specifically being bypassed.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware