Some questions on the es_event_mount_t and the es_event_remount_t structures

In the online documentation for es_event_mount_t, there are 3 fields listed for the es_event_mount_t structure:

  • statts
  • es_statfs_t
  • reserved

I only see 2 fields in Xcode 14 and 14+1 SDKs.

[Q] Is this a typo? If it is, I can file a feedback report.


In the documentation for es_event_mount_t, the documentation describes the statfs field as "The statistics of the mounted file system".

[Q] As the file system is not mounted yet in the context of an AUTH event, is it to be read as the "The future/request statistics of the mounted file system".

It's worth noting that the header documentation says:

The file system stats for the file system being mounted.

So it looks like the online documentation describes the field for the NOTIFY event and the header one for the AUTH event. This is a bit confusing.


In the documentation for es_event_remount_t, the documentation describes the statfs field as "The statistics of the remounted file system.".

[Q] As the file system is not remounted yet in the context of an AUTH event, is it to be read the "The future/request statistics of the remounted file system"?

[Q] In the case of a mount update, the statistics look more like the current statistics of the file system not the requested updated ones. What are these statistics supposed to be in this case?

The header documentation says:

The file system stats for the file system being remounted

which in the case of an update does not really clearly say whether this is the current or future stats.

Answered by DTS Engineer in 764434022

Is this a typo?

Yes. Well, not a typo, but definitely something wonky. Notably ESMessage.h contains this:

/**
 * This typedef is no longer used, but exists for API backwards compatibility.
 */
typedef struct statfs es_statfs_t;

which seems to have confused things.

If it is, I can file a feedback report.

Please do.


This is a bit confusing.

Yep. I think your interpretation is correct and I encourage you to include that in your doc bug.


What are these statistics supposed to be in this case?

I don’t have a definitive answer for that. You have a few choices here:

  • File a bug against the docs and wait for it to be clarified.

  • Look at the current behaviour and based your implementation on that.

  • Open a DTS tech support incident and I’ll get you a definitive answer.

Share and Enjoy

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

Accepted Answer

Is this a typo?

Yes. Well, not a typo, but definitely something wonky. Notably ESMessage.h contains this:

/**
 * This typedef is no longer used, but exists for API backwards compatibility.
 */
typedef struct statfs es_statfs_t;

which seems to have confused things.

If it is, I can file a feedback report.

Please do.


This is a bit confusing.

Yep. I think your interpretation is correct and I encourage you to include that in your doc bug.


What are these statistics supposed to be in this case?

I don’t have a definitive answer for that. You have a few choices here:

  • File a bug against the docs and wait for it to be clarified.

  • Look at the current behaviour and based your implementation on that.

  • Open a DTS tech support incident and I’ll get you a definitive answer.

Share and Enjoy

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

Closing the loop here, it seems that the statfs field always represents the state before the remount. That’s clearly less than ideal; in the auth event you want the new flags to determine whether to allow the remount or not. While investigating this I discovered that a different ES developer has already filed a bug requesting exactly that (r. 93832665).

Share and Enjoy

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

Some questions on the es_event_mount_t and the es_event_remount_t structures
 
 
Q