What's new? | Help | Directory | Sign in
Google
macfuse
A User-Space File System Implementation Mechanism for Mac OS X
Project Home
  
Downloads
  
Wiki
  
Issues
  
Source
    
Search
for
Updated Jun 30, 2008 by singh
Labels: Featured
CHANGELOG  
Changes/Feature Additions in MacFUSE Core Binary Releases

Changes and Feature Additions in MacFUSE Core Binary Releases

MacFUSE 1.7 (June 30, 2008)

MacFUSE 1.5 (April 25, 2008)

MacFUSE 1.3 (January 9, 2008)

MacFUSE 1.1 (November 6, 2007)

Improvements (Kernel)

Bugfixes (Kernel)

Improvements (User Space)

Bugfixes (User Space)

Build and Packaging Improvements

MacFUSE 1.0.0 (October 26, 2007)

Leopard Support

New/Improved Mount-Time Options

Improvements and Feature Additions (Kernel)

Improvements and Feature Additions (User Space)

Performance and Resource Consumption

Bugfixes (Kernel)

Bugfixes (User Space)

Introspection and Debugging Support

New/Updated Documentation

Build and Packaging Improvements

Specific File Systems

MacFUSE 0.4.0 (June 5, 2007)

MacFUSE 0.3.0 (May 7, 2007)

MacFUSE 0.2.5 (April 19, 2007)

Details: A common complaint of MacFUSE users (especially those using sshfs) is that the Finder, and sometimes other parts of the Mac OS X user interface, do not handle disruption in network connectivity well. Since version 0.1.9, MacFUSE has had the daemon_timeout option, which can be used to specify a timeout for the user-space file system to respond. If the kernel doesn't hear back from the daemon within that time, it will mark the file system as "dead". This will stop the Finder from "beachballing", but will also eject the volume instantly. To be more precise, it will arrange for the volume to be ejected. If you didn't specify the daemon_timeout option, the kernel would wait forever, although you can still kill the daemon or forcibly unmount the volume. MacFUSE 0.2.5 makes the situation more flexible. Now, there is a daemon_timeout (10 seconds) to begin with. If the daemon hasn't responded for that time, the kernel will show an alert dialog giving the user two choices: "Continue to Wait" or "Eject". Choosing the former will make the dialog disappear and the kernel will wait until either the daemon resumes responding or there's another timeout, at which point it will show the dialog again. Choosing "Eject" will arrange for the volume to be ejected instantly. The alert dialog itself has a timeout. If the user doesn't choose within some time (20 seconds), the dialog will disappear and the kernel will assume "Continue to Wait".
Details: After a successful unmount, sometimes (or often, depending on the circumstances) the user-space file system daemon doesn't exit, but continues to "hang around". The hang is benign in that you can easily get rid of the daemon (send it a SIGABRT or SIGKILL), but it's annoying nevertheless. The reason for this hang is the less than stellar behavior of Pthread cancellation on Mac OS X (and the FUSE library's dependence on pthread_cancel() and such). This is nontrivial to fix. MacFUSE 0.2.5 introduces a new option kill_on_unmount. If this option is specified, the kernel would send a SIGKILL to the daemon as the very last step of unmounting. This isn't so bad because before this, the kernel sends a synchronous FUSE_DESTROY message to the daemon, so the latter will still have an opportunity to shut things down gracefully.
Details: MacFUSE 0.2.5 pings Disk Arbitration by default (that is, it acts as if the ping_diskarb option was specified on the command line). For backward compatibility, you can still specify ping_diskarb. Conversely, if you do NOT want Disk Arbitration to be pinged, you now have to explicitly specify a new option: noping_diskarb.
Details: If a user-space file system daemon does not specify its subtype, andif the type cannot be inferred by the MacFUSE mount utility, MacFUSE will now use the string "Generic MacFUSE File System (MacFUSE)" instead of letting the Finder show the volume as of an unknown format.
Details: As a hack to get things working cheaply on Mac OS X, I had originally redefined __asm__(x) to nothing because the FUSE user library uses __asm__ with the ".symver" directive, which isn't available on Mac OS X. This is fine if the user file system daemon doesn't need to use __asm__ itself (unlikely). The daemon could include other headers that have __asm__ in there somewhere. In any case, redefining __asm__ is ugly, so the code no longer does that and uses other changes.

MacFUSE 0.2.4 (April 9, 2007)

MacFUSE 0.2.3

MacFUSE 0.2.2 (February 25, 2007)

MacFUSE 0.2.1 (February 15, 2007)

MacFUSE 0.2.0 (February 11, 2007)

Details: The new mount option 'novncache' can be used to turn off VFS name caching (name -> vnode lookups) in the kernel. This is useful when you want lookup operations to go to the file system daemon every time. This is useful in conjunction with the existing 'noubc' and 'noreadahead' options. So, if you use the combination '-onovncache,noubc,noreadahead', you should have a mount that will bypass most of the fcaching and go to the daemon every time. Of course, this would be slower. NOTE that if you're dealing with 32-bit executables, the situation is a bit more complex because of the "Task Working Set" caching mechanism in Mac OS X.
Details: 'nolocalcaches' is a meta option that is equivalent to 'noreadahead,noubc,novncache'. In particular, you can use '-onolocalcaches' along with the sshfs option '-ocache=no' to get file system behavior wherein most calls go to the server every time, resulting in a more up-to-date view of the remote file system, albeit with some overhead.
Details: The 'direct_io' mount option from Linux FUSE is now supported. This option can be used both at a file level or for the entire mount. To use it at a file level, your file system daemon should set the direct_io field of the fuse_file_info structure to 1 in the open() method. To use it for the entire mount, specify it as a mount-time option. 'direct_io' implies 'novncache', 'noubc', 'noreadahead' for the file (vnode) in question. Additionally, it forces the file system to be written synchronously ('nosyncwrites' is disabled for the /entire mount/, not just the file in question). But what does this option do (besides altering these above options)? Well, on Mac OS X, it introduces another read path from the kernel to the MacFUSE file system daemon. The new path does not go through the buffer cache (or the cluster layer). This allows you to specify one file size in the getattr() method and supply /less/ data in the read() method. Without the 'direct_io' option, MacFUSE will pad the missing data with zeros and return success. With the 'direct_io' option, MacFUSE will simply return the 'short' data and the read() call will not fail. This is useful when you don't know the size of the data for one reason or another (it's expensive to compute the size; it's not really possible to compute the size because you're streaming the data; etc.) Please NOTE: if an application insists on wanting the exact amount of data that you advertised in getattr(), 'direct_io' can't do anything about that, of course. The Finder is one such application.
Details: The MacFUSE kernel extension now logs a version message when you load it. The message is of the form:
MacFUSE: starting (version 0.2.0, Feb 10 2007, 10:34:26)
The date/time shown is a build timestamp. You can also view the version of a loaded MacFUSE kernel extension by using the sysctl command from the Terminal (just type 'sysctl macfuse' on the command line). This will allow a better approximation of which build you are running. Additionally, the mount_fusefs command now checks the version of the loaded fusefs.kext and bails out (by default) if there's a version mismatch between itself and the kext. If you really must, you can override this behavior by setting the MOUNT_FUSEFS_IGNORE_VERSION_MISMATCH environment variable.
Details: There's a preliminary advanced interface that file systems can use (don't use it just yet, unless you know exactly what you're doing and why) to do some weird things like: mark an existing vnode as "gone" (a variant of the revoke() system call), purge a node's in-kernel attribute cache, VFS name cache, or UBC. This interface will certainly change and evolve in future, so please don't create any dependencies on it yet.
Details: The limit (FUSE_MAXATTRIBUTESIZE) is defined in fusefs/common/fuse_param.h, and is 128KB by default. This matters because if you want to support writing larger extended attributes, you will need to tweak this parameter and recompile fusefs.kext. The 128KB value is not ad-hoc. The FUSE user-space library has an upper limit (approximately 128KB) on the size of the kernel channel" buffer--you will also have to increase this limit and recompile the user-space library. Besides, the following points apply to extended attribute sizes in Mac OS X:
- HFS+ supports a maximum inline attribute size of 3802 bytes. - However, HFS+ does support arbitrary sizes for resource forks, even though a resource fork is advertised as an extended attribute ("com.apple.resourceFork"). It's not a "real" extended attribute though--HFS+ intercepts this one and handles it itself. - The extended attribute handling code in the xnu kernel has an upper limit of 128KB on extended attribute data.
Details: MacFUSE now tries to be rather clever when dealing with extended attributes. If a user-space file system implements xattr functions, MacFUSE will pass on { get, list, remove, set }xattr() calls to user space. There are 2 exceptions to this: if the extended attributes happen to be those corresponding to Finder Info or Resource Forks. The reason for this: well, since regular extended attributes are subject to an upper limit (128KB by default), if we want arbitrary size resource forks, we have to treat them differently (like HFS+ does). MacFUSE treats them differently by telling the kernel to store them as Apple Double files. MacFUSE will also cause other attributes to be stored in Apple Double files if the file system daemon doesn't implement setxattr(). In fact, MacFUSE "learns" on the very first setxattr() call if the daemon implements this method or not--based on the return value. If the daemon doesn't implement the call, future setxattr() calls will not even go to user space: they will be short-circuited in the kernel, which will use Apple Double files. One noteworthy point here is that the kernel's generic xattr handling code (specifically the part that deals with Apple Double files) requires file locking (the O_EXLOCK flag to open) to work. This brings us to the next changelog item.
Details: Actually, MacFUSE always "had" advisory locking support. A file system in Mac OS X can get such locking for free by simply setting a flag. Unfortunately, Apple "forgot" to export this flag (rather, the function that sets this flag). Therefore, kernel extensions currently cannot set this flag without some sort of a kludge. Since advisory locking is rather critical now because extended attributes support requires it, I've decided to turn this flag on through cheap kludgy means (hardcoding the offset of a field in an Apple-private data structure). On the bright side, this means extended attributes will work nicely and you have locking available. On the flip side, if the aforementioned offset ever changes suddenly in a Mac OS X release, you might have a kernel panic :-) Apple really needs to export this function.
Details: You can now pass the 'extended_security' option at mount-time to enable support for ACLs on a MacFUSE file system. The ACLs that you get are identical to those in HFS+, except that they are stored in Apple Double files instead of being stored in the HFS+ attributes B-Tree. Of course, you can use the same commands ("chmod +a 'singh deny read'", "ls -le", etc.) to work with these ACLs. See the man page of chmod for details. IMPORTANT: If you want the kernel to honor these ACLs while accessing the file system, you also need to pass the 'noauthopaque' option at mount time. Without this option, the kernel will try to talk to the user-space daemon for authorizations. CAVEAT: The Apple Double files used to store ACLs have the default owner, group, permissions as a normal file would.
Details: MacFUSE now implements the necessary kernel functions for supporting the kqueue/kevent kernel event notification mechanism. See kqueue(2) on how you can use kqueue() and kevent() to use this mechanism on a MacFUSE file system. NOTE that implementing this mechanism in the kernel requires using unsupported Apple programming interfaces, which means that in future, it is possible that some revision of Mac OS X will not let this work. Therefore, the entire kqueue/kevent support in MacFUSE is a compile-time option that's conrolled by the MACFUSE_ENABLE_UNSUPPORTED macro in fusefs/common/fuse_param.h.
Details: Heh, I "improved" support for the 'nosyncwrites' option in at least two earlier releases, but I keep forgetting some detail. I'll need to explain the MacFUSE architecture to clarify why this is a bit tricky, but suffice it to say that asynchronous writes are never as easy on a "distributed"/"remote" file system as they are on a "local" file system. Unlike NFS on Mac OS X, MacFUSE doesn't have a special-purpose buffer cache either. That said, 'nosyncwrites' now follows sync-on-close semantics. As long as you have a file open, writes are asynchronous, but when you close the file, MacFUSE will sync it.

MacFUSE 0.1.9 (January 28, 2007)

Details: It handles SIGTERM/SIGINT hopefully properly now, and will try to automatically unmount the file system under most circumstances. Even when a file system daemon misbehaves and refuses to cooperate during termination, you should be able to force-quit the daemon and unmounting should proceed. Overall, this should result in much better experience, especially during file system development (when your daemons might be dying and misbehaving all the time).
Details: There is one notification sent right after a successful mount, one after the file system has initialized (the daemon has acknowledged FUSE_INIT), and another if there has been a timeout waiting for the file system to initialize. All these notifications are sent for an object called "com.google.filesystems.fusefs.unotifications". There is also a user-data dictionary in each notification. The dictionary at least contains the mount-path in question. See fusefs/common/fuse_mount.h for the names of these notification, etc. To learn how to receive these notifications, see the documentation for CFNotificationCenterAddObserver().
Details: By default, init_timeout is 10 seconds. If the file system does initialize within this time, mount_fusefs will ping Disk Arbitration (if the 'ping_diskarb' option was specified) and send the "inited" notification to the distributed notification center. If there is a timeout, mount_fusefs will not ping Disk Arbitrarion (even if the 'ping_diskarb' option was specified) and will send the "inittimedout" notification. Helper programs can use this mechanism to decide if they need to do any cleanup etc.
Details: If the daemon fails to respond within this time, the kernel marks the file system as "dead". By default, there is no timeout -- the kernel will wait indefinitely (unless you kill the file system daemon yourself). This should stop the Finder from "beachballing" -- BUT AT THE COST OF EJECTING YOUR VOLUME REGARDLESS OF WHETHER YOU HAVE FILES OPEN IN THAT VOLUME. There will be a VFS-level kernel notification sent out that causes the Finder to eject the volume (remember to use the 'ping_diskarb' option). This ejection is /forced/ -- if you have files open when the file system became "dead", they will be unceremoniously ignored. The alternative (you can modify the source to do so) is to not eject forcibly if files were open. Since the file system is dead, it's not like you would be able to "save" them -- it's just that you will have to eject it later manually after you've "closed" those files. An even better alternative would be to have support from going back-and-forth between "dead" and "alive" states (based on a network connection coming and going, for example) but that's for later. In any case, the goal is that "killing" the file system daemon ("kill <daemon's process ID>") should always work. PLEASE READ THIS CAREFULLY AND USE THIS OPTION WISELY. YOU CAN KILL THE FILE SYSTEM DAEMON WITHOUT HAVING TO RESORT TO THIS OPTION. ONCE YOU KILL THE DAEMON, THE Finder WILL STOP BEACHBALLING TOO.
Details: This fixes the problem where Disk Utility and Startup Disk preference pane get confused because the description they are looking for is not found in fusefs.fs's plist.

MacFUSE 0.1.8

MacFUSE 0.1.7 (January 22, 2007)

MacFUSE 0.1.0b006 (January 14, 2007)

MacFUSE 0.1.0b005 (January 11, 2007)

MacFUSE 0.1.0b004 (January 9, 2007)