Short answer: NO. For a long answer, read on. Understanding better how things work always helps one write better programs.
To begin with, "FUSE" is an API--a specification, if you will. MacFUSE implements the FUSE API (among some other things) on Mac OS X. When talking about these things, at least among developers, it is good to be correct and precise. When an application opens a file for reading on a MacFUSE volume, the following things happen. As a first step the, application will open the file for reading. The application will directly or indirectly use some file API--for example, NSFileManager, Carbon File Manager, or the C-library level "BSD" API (the typical open, close, read, write system calls). No matter which interface is being used, eventually, it will lead to the open system call. Look at the man page for the open system call (man 2 open). You will see that although it is aware of the mode that the file should be opened in (for reading, for writing, for both, among other specifiers), you don't get to specify your intention regarding how much data you want to read from the file. The OS architecture also doesn't lend itself well to such a specification either. The open system call handler stub in the C library will cause the transition to kernel space. After several authorization and preflight checks, the kernel's open system call handler will invoke the in- kernel file system's handler function for open. In our case, the in- kernel file system is MacFUSE (implemented in the fusefs.kext kernel extension). The MacFUSE kernel-level open handler would want a MacFUSE "file handle". In some cases, it will reuse an existing handle from a previous open of the file. If this happens, you will not see an openFileAtPath call at all. In some other cases, it may send that call back to user space. This is the crux of the user-space file system concept--usermode programs get to serve file system requests. In user space, it's your file system code linked against the libfuse library that will handle the open request. The entire chain looks like this, starting from the application trying to open a file: [USERMODE] Application ==> Possibly Cocoa/Carbon => C library open ==> [KERNELMODE] Kernel open syscall handler ==> Virtual File System (VFS) open handler ==> MacFUSE open handler [USERMODE] libfuse open handler (FUSE Low Level API) ==> libfuse C API (FUSE High Level API) ==> MacFUSE.framework (MacFUSE ObjC API) ==> Your ObjC file system program sees openFileAtPath When you return from openFileAtPath, the reverse sequence will occur all the way back to the kernel. Anyway, the reason I want you to know this is because a statement like "If FUSE is called by an application, initiated by the user double clicking a file in the GUI" is extremely vague. That said, why do you care about this? Perhaps you want to "prefetch" the file if you somehow "know" that it will be read in its entirety, or something like that. That's not quite how the operating system works though. Although the kernel can actually detect sequential and reverse sequential I/O and can do read-aheads/behinds if it deems fit, it still won't tell you at open time that "I am opening this file for reading and I will be reading the entire contents." If you want to experiment and use your own heuristics, you can usually tell in your usermode file system which application is causing the open or read request to occur. You could then try to deduce, say, based on known application I/O patterns, how the file would be read. It might be an interesting academic exercise, but that's about it. Amit On Oct 30, 2:51 pm, Jason8 <[EMAIL PROTECTED]> wrote: > Hi: > > If FUSE is called by an application, initiated by the user double > clicking a file in the GUI: Is it possible to determine when open > (openFileAtPath) is called, if it is an application asking to open a > portion of a file for reading, or if it is asking to read the entire > file? > > Thanks, > Jason. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
