


Regardless, the Drive File Stream driver adds a mechanism for reading special metadata attached to file/folder's located within its file system.

Perhaps Google's file system driver is simply emulating the behavior of NTFS alternate data streams. The thing is, the properties of Drive File Stream's virtual drive show it as being partitioned as FAT32 which do not support alternate data streams. I do not know exactly what mechanism allows for the functionality described below, but it is nearly identical in function to the way NTFS alternate data streams work. Although I found this functionality on a Windows system, there may be similar functionality on Mac OS X. I recently discovered a much more efficient way of retrieving the Drive API 'File ID' of any given file/folder located within your Google Drive File Stream file system.
