Yoram Arnon wrote:
Modifying a structure in an API requires recompilation of the apps that use it, so growing it is also undesirable.
Recompiling should not be difficult. If that is truly a concern, then we should not use a struct, but instead a void* and a set of functions to access it, or perhaps somehow version-stamp the API, so that the server/library can operate back-compatibly.
Having a couple extra values that are set to some default value before they're fully supported is common enough, and imposes minimal overhead.
Regardless of what we have there today, chances are we will someday need to be able to add things to the stat. We don't want to forever be saddled with unused fields. If nothing else, we'll end up wasting time explaining to folks that they don't work.
I'd add anything that's remotele relevant from 'stat' to dfsFileInfo.
-1 We are not building a unix FS. For example, the file mode, uid, and gid are remotely relevant, but, until we design a permission scheme, these should not appear in dfsFileInfo. We are unlikely to ever support access-time, but it is remotely relevant, and we may someday.
Doug
