On Oct 22, 5:26 pm, Ron Aldrich <[EMAIL PROTECTED]> wrote: > Since the backing store for the FS is an actual /dev/disk, I'd like > it to show the volume icon provided by the device driver, in the same > way that the HFS file system does. Implementing the destroy method > in the FS to eject the physical disc should work, but I know that the > association between a file system and it's device vnode is normally > maintained by the OS, and I'd like to come up with a way to use the > existing mechanism, if possible.
Well, "normally" the file system isn't provided by a user-space program! The entire point of MacFUSE is to let a *user-space* program take care of the backing storage. Whatever existing mechanism(s) you're probably thinking of are not applicable here. As for the icon, I'd reiterate my suggestion: please look at the 'volicon' option. It's documented in the MacFUSE wiki. > I guess I have some research to do in order to determine how that > mechanism currently works. Yes. Also note that what applies to Linux (or Linux FUSE) doesn't necessarily apply to Mac OS X or MacFUSE. The user-space library (libfuse) is a port of the Linux version, but the MacFUSE kernel extension is completely different from the Linux version, so don't expect nuances, caveats, features, etc. to be identical across the two. > >> 2) The volume cannot be renamed. Is there a way to support this? > Looks like I'm going to be needing to add that, then. How adverse > are you to adding Mac specific APIs? I'm not keen on extending the API just yet. I have added numerous Mac specific things in the past, but volume renaming will have to wait for now, since I have some higher priority things to take care of. As you probably realize, it's not just a matter of adding a field to a structure or adding a new function: if things have to be done in a foolproof, backwards compatible manner, many kernel/user components will have to be extended (and volume renaming isn't the only thing I want to add--there are other things too). It doesn't sound like this is a need of crisis proportions for you--if that's the case, I'd advise waiting a bit on this one. > I was hoping that bmap might be a way to achieve some support for the > unified buffer cache, at a per file level. Currently the best that > can be hoped for is that the UBC will associate all of the files on > the volume with a single vnode (the device's vnode). > > MacOS (as of 10.4) uses the "blockmap" function to allow files to be > memory mapped, and to support cluster mapped I/O. > > Within the blockmap function, a file system describes a file's > extents in terms of blocks, allowing the operating system to bypass > the "read" and "write" codepaths within the file system, and perform > the I/O itself using the unified buffer cache. Of course, this only > works if the file's contents are stored on a block device, and are > block aligned. > > At any rate, I don't think that bmap is a good fit, as it seems to > have been written to provide a mapping between a single block in the > file and a single block on disk, rather than an extent within a file, > and an extent on disk. Are you expecting that MacFUSE simply pushes the entire *vfs* interface to user space? If so, that's not how it works! MacFUSE itself uses cluster I/O, but it doesn't just forward every vnode/vfs/ cluster I/O operation to user space. That's not its goal--it's goal is to provide a vastly simpler file system programming interface (than the vfs, say). The data that you provide from your user-space program to MacFUSE /does/ go through the UBC. In your user-space file system, you'll simply get read/write calls for file data. What exactly are you looking to do? > As I recall, there is some connection between resource forks and > extended attributes under 10.5? Does that imply that the size > parameter in setxattr can be very large? Attributes such as "com.apple.ResourceFork" and "com.apple.FinderInfo" are mapped to resource forks and Finder info. There are others (for ACLs and such). Since xattrs can't be seeked into (like files), the size can't be arbitrarily large. I'm still toying with the size and when I release the next major version of MacFUSE (very soon), I might go with something like 4MB for the size limit. That is, you'd be limited to 4MB per xattr. This is much larger than the limit HFS+ has (~ 4KB), but HFS+ resource forks don't go through this path, so they can be arbitrarily large. If you want larger than 4MB resource forks in MacFUSE, you'll have to resort to using AppleDouble files for them. Amit --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
