Thanks a lot in the first place.
What does the interface for this actually look like? Is it presenting its own file navigation UI (I suspect yes) or is this the open/save panel? Similarly, when looking at the other things you tested:
You are right, that most apps like Word, Safari and other applications that I have tested indeed use system-like navigation, with open/save buttons, while this program indeed has a separate UI, listing only media files and directories and it is simply different from Finder UI.
Regarding the cases you have asked to test.
Setup as controlled a test as you possibly can, with minimal directory contents and external interactions.
The ideal here is that the ONLY VFS activity that's occurring is coming directly from the app your trying to understand.
You can often figure out what's going on by first isolating the issue (as above) then closely examining EXACTLY what every vfs operation returned.
I have been sitting with samba and my driver with dtrace for around a week, comparing every field and every return code.
This might be too specific detail, but from what I have seen is that the app (Adobe Media Encoder) follows the below pattern on query:
- Firstly entering vfs driver, we get a vnop_open for root directory and exactly four readdirs for root (both samba and my driver have around 2-3 files and 1-2 subfolders, not much so everything is read in one vnop_readdir call). This is identical for both samba and my driver.
- Upon double-click on "subfolder", the following algorithm is initiated: For samba everything works correctly and logical - vnop_open for root, once again four readdirs for root, vnop_open for "subfolder" and readdir for "subfolder". However, for my driver, the behaviour is: vnop_open for root, four readdirs for root
And that's all. No more queries, no more requests, no aborting "vnop_open" calls, nothing. Afterwards, even renavigating back to my root will not work inside Adobe - the driver will simply represent itself as empty.
The man page for "opendir" has a snippet showing "basic" POSIX style directory iteration and that's the first thing I would test with. As I talked about above, that's not the approach most of our APIs would use, but it is the approach someone implementing their own iteration might use, particularly if they were focusing on something like cross platform support.
Yes, I have tried their example program, and I do get a proper output with my objects, whether they are indeed found, so this one works.
If "opendir" works, then it would probably be worth testing with the Carbon File Manager.
For this one, I wrote a little program
#include <Carbon/Carbon.h>
#include <stdio.h>
void listFilesInFolder(FSRef *folder) {
FSIterator iterator;
FSCatalogInfo catalogInfo;
FSRef fileRef;
ItemCount actualFetched;
if (FSOpenIterator(folder, kFSIterateFlat, &iterator) != noErr) {
printf("FSOpenIterator failed\n");
return;
}
while (FSGetCatalogInfoBulk(iterator, 1, &actualFetched, NULL, kFSCatInfoNone, &catalogInfo, &fileRef, NULL, NULL) == noErr && actualFetched > 0) {
char filePath[1024];
if (FSRefMakePath(&fileRef, (UInt8 *)filePath, sizeof(filePath)) == noErr) {
printf("File: %s\n", filePath);
}
}
FSCloseIterator(iterator);
}
int main() {
FSRef folderRef;
if (FSPathMakeRef((const UInt8 *)"/Volumes/myvfs/mysubfolder", &folderRef, NULL) != noErr) {
printf("FSPathMakeRef failed\n");
return 1;
}
listFilesInFolder(&folderRef);
return 0;
}
And I also properly retrieve all objects inside that subfolder. So I might say that carbon file manager works either.
However.
I would take a look at what you're returning for volfs support and persistant ID support.
I do not have MNT_DOVOLFS in mount flags. Attempting to set it on actually breaks some things and applications. The volume changes the icon in GUI apps, also in the Adobe Media Encoder once again the driver is no longer even showing the root folder.
For persistent object ids (VOL_CAP_FMT_PERSISTENTOBJECTIDS), I do have this one enabled, however, I am not sure I am doing anything to actually "support" it.