On Mar 26, 2008, at 7:57 PM, Amit Singh wrote:
> Please realize that your "UDF Volume" is *not* a UDF volume--it's a > MacFUSE volume. It's also not a disk-based file system (like it would > be in the case of an in-kernel UDF driver)--it's a MacFUSE file > system. This is *really* critical to understand. As far as MacFUSE is > concerned, the file system's "backing store" is a program in user > space. MacFUSE doesn't really care if the actual data is coming from a > "real" disk node or from elsewhere. > > In the Mac OS X kernel, what's reported as st_dev is the va_fsid vnode > attribute. In the case of a real disk-based file system (like HFS+), > the file system would arrange for va_fsid to be set to the underlying > device number (a dev_t composed from major and minor numbers). When > you do a stat, you get this value back in st_dev. This is not the case > with MacFUSE. As I said above, MacFUSE doesn't care where the user- > space file system stores its data. MacFUSE sets va_fsid to an > automatically generated value (that's guarded against clashes). This > value is unrelated to the block device your user-space file system > might be using. > > Contrary to what you might expect, it's neither straightforward nor > desirable to have a real block device show up in a MacFUSE volume's > st_dev. A Mac OS X file system is either block-device based or isn't-- > several things differ between the two, including the argument > structure used in the mount system call. MacFUSE, by design, is *not* > block-device based. Forcibly stashing a specific st_dev value isn't > safe either. You could seriously confuse things like Disk Utility.app. > Besides, there are no provisions to stop a user from specifying an > st_dev value that happens to be the same as that of the root volume, > etc. Is the difference here inherent to all user space file systems? Or simply a limitation imposed by MacFUSE's design? > > Finally, the purpose of "-ofsname=/dev/diskN" is *not* to set up > st_dev "properly". It's purpose is to merely specify the string that > should be reported as the f_mntfromname field of the statfs structure. Frankly, the only reason I want st_dev to point to my filesystem's physical backing store is because Apple changed the rules for determining whether a volume is network based between Mac OS X 10.4 and 10.5. In 10.4, Finder identifies my FS as a local volume, and uses a trash folder, as expected. In 10.5, Finder decides it's a network volume, and insists on deleting files immediately. This is the problem I'm trying to resolve. > It's not that I'm totally oblivious to why you'd want what you were > expecting. It just doesn't work that way. I could, in theory, add an > argument that would let you specify an st_dev value (or, if fsname > happens to be of the form /dev/diskN, take the st_dev value from > there, but as I alluded to above, it wouldn't be without caveats/ > dangers). > > Amit Everything here is not without caveats and dangers - even though my filesystem is being implemented in user space, I'm pretty sure I could manage to bring the entire system down in flames, if I really put my mind to it ;-) The real question, is would it work? (And would it even solve the trash folder problem, or am I just chasing after wild geese?) Thanks for your time, Ron Aldrich Software Architects, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
