John, Amit, and others:
I'll apologize up front for my severe case of "too long; didn't
read." That said, I understand your efforts to make this work
properly for filesystems that the default `fusefs.fs` bundle doesn't
know about. Your solution works in most cases, but seems to be a
hack around a deeper problem. I think I've come up with a viable
alternative.
Since my employer has asked I not continue my distribution and
development of NTFS-3G packages for MacFUSE, I've begun documenting
everything I can to help the community recreate my efforts. My first
article is about filesystem bundles, and the section on
`FSPersonalities` is of particular interest:
http://shadowofged.blogspot.com/2007/07/mac-fs-filesystem-
bundle.html#kFSPersonalities
Apple uses a private framework called DiskManagement, which I
*believe* is responsible for obtaining all of the filesystem
information. I believe it finds strings for volumes using an
algorithm similar to the following:
1. statfs() the mount point to get the `f_fstypename` and
`f_reserved1` (fssubtype) values
2. Locate the filesystem bundle of the form `<f_fstypename>.fs`
3. Locate a matching personality in that bundle, using the
`fssubtype` value
4. Translate `FSName` key by looking for matching
`FSPersonalities` keys in language projects
Since all MacFUSE volumes pass through `mount_fusefs`, they all have
their `f_fstypename` set to "fusefs". This, in turn, causes all
lookups to happen in `fusefs.fs` (if my assumptions are right). This
is because of how the `mount()` syscall works. The first parameter
is the `f_fstypename` value, which is used to locate the VFS plugin
that will mount the filesystem. Since we all use the MacFUSE kernel
code, this cannot change.
HOWEVER, this info is copied into a per-mount `vfsstatfs` structure,
and the VFS code is never referenced by name after `mount()` is
called. Thus, MacFUSE could theoretically lay down a custom
`f_fstypename` value inside its `vfs_mount()` routine.
So, I propose adding a `fstype=` or `fstypename=` option to
`mount_fusefs` that would let MacFUSE filesystems set their own
`f_fstypename`. This would of course be opt-in, and filesystems that
don't pass this option would see the old behavior. Since some
programs might still need to discover MacFUSE mounts even if they set
a custom `f_fstypename`, we must still provide a deterministic way of
doing that.
IMPORTANT NOTE: Currently, the kernel calls `bzero()` on the
`vfsstatfs` structure so that every new `f_fstypename` is GUARANTEED
to be zero-filled beyond the end of the string. We can take
advantage of this, as discussed below. However, since it's not
necessarily required, that behavior may change later (but I doubt it).
So, here is the proposed method, and its limitations:
1. Without `fstype=`, leave `f_fstypename` as the default "fusefs"
2. With `fstype=`, set `f_fstypename` to the argument passed
3. For all "fusefs" mounts, put a magic 32-bit integer at the end
of the `f_fstypename` field
A likely candiate would be FUSE_CUSTOM_FSID_VAL1, which is 'UFES'.
This would be stored in an endian-dependent manner. It would limit a
MacFUSE `fstype=` to 11 characters (plus terminating NULL) instead of
the specified MFSNAMELEN of 15 characters plus a NULL. However, 11
characters is still a lot, and this is a much more elegant solution
than cramming everything into `fusefs.fs`.
Thus, programs only checking `f_fstypename` would see what is
(largely) the desired behavior for that filesystem, but apps that
know to check the last 32 bits of `f_fstypename` could still
accurately find all MacFUSE filesystems. There would be no mistakes
with real VFS plugins that happen to have very long `f_fstypename`
fields, as they would include a NULL-terminator, and the magic
constant does not.
Please let me know what you think. It seems safe and viable to me...
is there anything this would break?
Best regards,
- Paul Marks
On Mar 17, 2007, at 7:36 PM, John Brisbin wrote:
> In most respects, the MacFUSE supports file system modules cleanly.
> One exception is that name of the file system that appears in the
> Get Info window of the volume, folders and files presented by the
> file system, for example, "Format: SSH File System (MacFUSE)."
>
> [...]
>
> To address this problem, I have implemented the following protocol
> (which I hope will be adopted into the official release) for
> dynamic updates to the fuse file system personalities table:
>
> 1. The mount_fusefs tool is used to maintain and update the
> personalities table. The mounting tool has the information needed
> to perform any updates and can securely perform those updates. It
> also resides in the same package, resolving any locational ambiguity.
>
> 2. A hierarchy of procedures is used to extract the most meaningful
> name for the file system from the available information. Since the
> lookup key is the fsname string, that string is defined in each
> case as either the value from an fsname= command line argument or
> the name of the file (argv[0]) implementing the file system.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
