Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Operating Systems Software

FUSE Port Brings NTFS Support To OS X 150

Posted by kdawson from the circuit-breaker dept.
sciurus0 writes "In his session at Macworld on OS X filesytems, Google's Amit Singh announced that he has ported Linux's FUSE module to OS X. The port is called MacFUSE and it is available in source form and as a pre-compiled kernel extension with associated tools. Many FUSE filesystems such as sshfs and ntfs-3g are reported to work."
This discussion has been archived. No new comments can be posted.

FUSE Port Brings NTFS Support To OS X More

FUSE Port Brings NTFS Support To OS X

Comments Filter:

  • GmailFS also (Score:5, Informative)

    by Anonymous Coward on Wednesday January 17, 2007 @05:53AM (#17643608)
    GmailFS [jones.name] should also now be easily supported on Mac OS X using MacFuse.

  • FUSE for Windows (Score:5, Interesting)

    by Cyberax ( 705495 ) on Wednesday January 17, 2007 @05:53AM (#17643614)
    I'm writing FUSE for Windows at my spare time (not much of it, unfortunately). Is there anybody who's doing the same?

    • Re:FUSE for Windows (Score:2)

      by j-pimp ( 177072 ) <zippy1981@noSpam.gmail.com> on Wednesday January 17, 2007 @06:03AM (#17643672) Homepage Journal
      Is this going to use the same modules as FUSE for linux? This sounds interesting. I'm willing to test when you feel reasonable it won't make my machine particularly unstable for windows.

    • Re:FUSE for Windows (Score:1)

      by thaig ( 415462 ) on Wednesday January 17, 2007 @09:24AM (#17644832) Homepage
      Intriguing idea. Have you got a website for this effort?

      I have been thinking about making a FUSE filesystem for Linux and having it on Windows as well would be a great advantage.

    • Re:FUSE for Windows (Score:2)

      by wandazulu ( 265281 ) on Wednesday January 17, 2007 @12:26PM (#17647576)
      This would be great, as then Windows would be able to read (and presumably write) to HFS+ file systems. I could finally use my Mac-formatted iPod on a windows machine!

    • Re:FUSE for Windows (Score:3, Interesting)

      by Foolhardy ( 664051 ) <`csmith32' `at' `gmail.com'> on Wednesday January 17, 2007 @01:51PM (#17649058)
      I have thought about porting FUSE in the past, since it'd be a great way to enable lots of filesystems in Windows but haven't gotten out of the planning stage. I'd be very interested in helping to make that happen. I have some experience [dyndns.org] in writing Windows NT filesystem drivers.

      I don't know how you've planned the userspace, but I'd suggest that you make it NOT dependent on Win32. It'd be much easier to implement features like fork (which Win32 doesn't support, but native processes do). Also, native process programming follows a lot of the same conventions that kernel programming does; the code would be more consistent and lightweight. Besides, it seems unlikely that FUSE would require Win32-specific features.

      Please let me know if you get a source repository up.

    • Re:FUSE for Windows (Score:2)

      by teridon ( 139550 ) on Wednesday January 17, 2007 @07:51PM (#17655842) Homepage
      Would using Microsoft Services for UNIX [microsoft.com] help you port it?

  • The creator of FUSE... (Score:5, Informative)

    by little1973 ( 467075 ) on Wednesday January 17, 2007 @06:24AM (#17643750)
    ...Miklos Szeredi was offered a job by SUSE Labs, Prague, which he accepted. His job will be kernel developement for SUSE (all GPL, of course). IIRC, he can work on FUSE in 10% of his work time.

  • Precompiled read/write NTFS packages (Score:5, Informative)

    by irgu ( 673471 ) on Wednesday January 17, 2007 @06:36AM (#17643812)
    The original NTFS-3G [ntfs-3g.org] source code doesn't compile on Mac OS X without some changes but the MacFUSE and NTFS-3G precompiled packages [iusethis.com] are available from IUseThis.

  • Great for dual booting? (Score:3, Interesting)

    by Max Romantschuk ( 132276 ) <max@romantschuk.fi> on Wednesday January 17, 2007 @06:45AM (#17643862) Homepage
    Boot camp users, care to comment on the implications?

  • Great News! (Score:3, Insightful)

    by RAMMS+EIN ( 578166 ) on Wednesday January 17, 2007 @07:07AM (#17643964) Homepage Journal
    This is great news! Finally, there's an easy way to develop filesystems for multiple operating systems. Maybe I'll pick up my netfs project again now. Anyone working on porting FUSE to *BSD?

    • Re:Great News! (Score:3, Informative)

      by jack_csk ( 644290 ) on Wednesday January 17, 2007 @08:39AM (#17644494)
      I'm not sure about NetBSD and OpenBSD, but then fusefs support is already in FreeBSD.

      By the way, I have decided not to upgrade my OS X until Apple includes out-of-the-box sshfs (that's the one I used the most among those built on top of fuse) support into new version of the OS.

    • Re:Great News! (Score:2)

      by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Wednesday January 17, 2007 @09:35PM (#17657190) Journal
      Care to share your ideas on this netfs project of yours? I was planning something similar...

      But more seriously, I'd pick a platform and stick to it -- and right now I like Linux, because it's so ubiquitous. If you're looking for a cross-platform way of developing filesystems, you might consider trying some sort of wrapper library in-kernel, though...

      Because FUSE is slow, and FUSE will always be slow. The way I understand it, even a filesystem that creates exactly one file that simply reads "hello, world", is going to take four context switches to read that file. Consider "cat foo": cat -> kernel -> FUSE daemon -> kernel -> cat

      I'd like to look more deeply into this sometime, though. I remember back when Hans Reiser was introducing Reiser4 and "plugins", and others were saying that Linux already has a filesystem plugin layer -- the Linux VFS, which all other filesystems use. So, I want to know if the Linux VFS itself is portable enough to target that instead...

      • Re:Great News! (Score:2)

        by RAMMS+EIN ( 578166 ) on Thursday January 18, 2007 @02:46AM (#17659682) Homepage Journal
        ``Care to share your ideas on this netfs project of yours?''

        The main idea was to first make a simple read only filesystem that Just Works. That part is basically done, except there is no kernel driver yet. Then, the filesystem would be extended with permissions (done right; not based on uids like in NFS) and write support. Eventually, it's on to replication and perhaps distribution.

        ``But more seriously, I'd pick a platform and stick to it''

        I would, but writing filesystem drivers for any platform is a PITA. I ran into lack of documentation and comment-less source code on Linux, and on NetBSD and OpenBSD, all I managed to do is lock up the system. With FUSE, it's all so much easier.

        ``Because FUSE is slow, and FUSE will always be slow.''

        I doubt that matters when you're interacting over the network anyway. Besides, the first priority is making it work; a kernel driver can always be written if need be. Premature optimization is the root of all evil, yada yada.

        ``I want to know if the Linux VFS itself is portable enough to target that instead...''

        It's not. Also, it's poorly documented, poorly commented, and you never know when the API will change.

        • Re:Great News! (Score:2)

          by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Thursday January 18, 2007 @03:50AM (#17660034) Journal
          Then, the filesystem would be extended with permissions (done right; not based on uids like in NFS) and write support.

          Hmm. How does that look? I can see some sort of mapping local uids to remote uids, or more advanced schemes like ACLs, but other than that...

          Eventually, it's on to replication and perhaps distribution.

          I'm guessing that means a file can be stored on more than one machine, and it will be cached on-disk locally? Basically, like coda, but open?

          Sounds good!

          I doubt that matters when you're interacting over the network anyway.

          LANs are pretty fast, and then there's gigabit. With aggressive caching, you should be able to make really nice "diskless" machines, where you have a box with 20 gigs or so of disk space, but which boots and runs from the network (from a fileserver or a cluster of fileservers), using that only as a local cache -- the administrative benefits of diskless combined with the performance characteristics of local installation.

          Unfortunately, I've never found a network FS that I like for that purpose, and the few that were close enough to try, I could never get to work.

          Premature optimization is the root of all evil, yada yada.

          True enough, to a point. I guess I always want to make sure that I'm optimized enough in the beginning, so I wouldn't have to rewrite the whole entire app for performance considerations. For instance, I'd hate to, say, write a game in Perl, then have to rewrite the whole thing in C++ just for the performance.

          Then, too, I want more out of my environment (language, tools, OS) than anything provides right now, which means I'd better get started!

          • Re:Great News! (Score:2)

            by RAMMS+EIN ( 578166 ) on Thursday January 18, 2007 @08:53AM (#17661844) Homepage Journal
            ``Then, the filesystem would be extended with permissions (done right; not based on uids like in NFS) and write support.

            Hmm. How does that look? I can see some sort of mapping local uids to remote uids, or more advanced schemes like ACLs, but other than that...''

            I'm thinking just authentication to the netfs server. Any kind of authentication could be implemented, and any mapping between netfs accounts and system accounts on the system the server runs on. I still have to think about it.

            ``Eventually, it's on to replication and perhaps distribution.

            I'm guessing that means a file can be stored on more than one machine, and it will be cached on-disk locally? Basically, like coda, but open?''

            Yes, caching too, I forgot to mention that.

            ``Sounds good!''

            Thanks! It's all still very much in the future, though. I'll probably have to rewrite the existing code, because the files seem to have gotten corrupted.

            ``I doubt that matters when you're interacting over the network anyway.

            LANs are pretty fast, and then there's gigabit.''

            Yes, but you're still incurring context switches and network latency, which I imagine adds up to more than the FUSE overhead.

            ``With aggressive caching, you should be able to make really nice "diskless" machines''

            Caching is far off, though. The algorithms for keeping replicas consistent are complicated, and I want to make the simple stuff _work_, before I start on complicated stuff and optimization.

            ``Unfortunately, I've never found a network FS that I like for that purpose, and the few that were close enough to try, I could never get to work.''

            Same here, with the added complication that I run multiple operating systems. That's why I started netfs. Unfortunately, developing the kernel modules was too high a barrier for me.

            ``Premature optimization is the root of all evil, yada yada.

            True enough, to a point. I guess I always want to make sure that I'm optimized enough in the beginning, so I wouldn't have to rewrite the whole entire app for performance considerations. For instance, I'd hate to, say, write a game in Perl, then have to rewrite the whole thing in C++ just for the performance.''

            I always prototype code in a dynamic language (Python in this case; usually Scheme or Ruby). Then, once I'm satisfied with the design, I consider rewriting in another language. Often, I don't bother, or just rewrite the hot spots.

            ``Then, too, I want more out of my environment (language, tools, OS) than anything provides right now, which means I'd better get started!''

            I'm working on my own programming language (Mana), which is meant to be (1) fit for interactive use; specifically, as a shell, and (2) be suitable for large projects as well. Important features are: simple and convenient syntax, macros, strongly typed, compiles to native code, automatic resource reclamation (memory, but also file handles and whatever else one implements), and dependent types if I can figure out a way. Right now, the design is mostly finished, as is the code generator; next up is implementing the core language (abstraction of machine code), then the base language (minimal type-safe language on which the rest will be built), and then I'll have to sit down and think hard about the standard library. The language is strongly influenced by Common Lisp, Scheme, Haskell, and the Bourne shell.

            • Re:Great News! (Score:2)

              by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Thursday January 18, 2007 @05:50PM (#17671376) Journal

              Yes, but you're still incurring context switches and network latency, which I imagine adds up to more than the FUSE overhead.

              Consider NFS. With NFS, you have exactly the number of context switches you would on a local FS -- you go app -> kernel -> remote kernel -> kernel -> app. The kernel is doing all the network stuff, all the filesystem stuff, and all the NFS stuff.

              But definitely once you get into caching -- I know you're putting that off, and I'd also encourage you to look at the fscache/cachefs... whatever they're calling it, there are people working on a solution for caching NFS stuff. What I'd really like to see is something like the FUSE caches that exist now, but in kernel space -- to, say, mount /nfs onto /cached, and have it all cached as local files within /cached, the way InterMezzo was supposed to work -- letting me do things like use Reiser4 for a local cache, if I'm so inclined.

              Same here, with the added complication that I run multiple operating systems. That's why I started netfs. Unfortunately, developing the kernel modules was too high a barrier for me.

              If you can make it work well with one OS, you're likely to find people to help you port. I'd be all for portability if it weren't for what I see as potentially massive performance issues...

              I'm working on my own programming language (Mana), which is meant to be (1) fit for interactive use; specifically, as a shell, and (2) be suitable for large projects as well.

              Those are two of my three (or is it four now?) requirements from a language, before starting my own ambitious projects.

              Important features are: simple and convenient syntax, macros,

              Good... For my part, I want it to be something like Perl, and especially like Perl6 and Ruby, in that large chunks of the language can be written in or modified by the same language. I'm guessing macros will help with that...

              strongly typed

              Good for performance, I think. I'd suggest that strongly typed doesn't mean we can't do the kind of implicit typecasts everyone likes -- and, for that matter, I don't see dynamically-typed languages having their dynamic typing taken advantage of.

              compiles to native code

              I like bytecode. Partly because I occasionally hear of benchmarks where a VM outperforms native code -- it can do optimizations at runtime that aren't really possible at compile time; for instance, pick one of two possible implementations based on which performs best under the current workload.

              But mostly, I like bytecode because I want my software to be portable at that level. One of my ambitious projects may be proprietary, or at least encourage proprietary development, and languages like Java kind of force people to be cross-platform without having to really think about it. And the ambition of my project is such that I'd want 90% of office-like apps to be written in it, making the business world no longer platform-dependent.

              There are some reasons I think this will work, but this may be getting beyond what I want to talk to on Slashdot. I'm partly paranoid of my ideas being stolen, partly paranoid of being laughed at, but it would also be nice to have this in email or something else. My Jabber ID is the same as my email address, if you want to talk.

              In any case, an intermediate representation (bytecode) should be possible to compile down to machine code. In fact, gcj does just that for Java.

              automatic resource reclamation (memory, but also file handles and whatever else one implements)

              In this case, I think it'd be nice to have this be possible to fine-tune for a particular app. To have everything managed, but have the app (or object, or library) be able to force reclamation, at least.

              Might also be nice to either fi

  • Doh. mount_ntfs is already there (Score:2, Informative)

    by Tetard ( 202140 ) on Wednesday January 17, 2007 @07:13AM (#17643994)
    I use it everyday...

    # which mount_ntfs /sbin/mount_ntfs

  • Great! (Score:3, Informative)

    by jack_csk ( 644290 ) on Wednesday January 17, 2007 @08:16AM (#17644334)
    I was waiting for the sshfs support on Mac OS X for a long time.
    Thanks Google, you did us OS X users a great favorite!

    • Stability: SSHFS or MacFUSE at fault? (Score:3, Interesting)

      by jdbartlett ( 941012 ) on Wednesday January 17, 2007 @03:48PM (#17650980)
      It's a great tool and one I have practical use for, but testing it out for work I've stumbled across what I consider to be an important issue. I've only tried SSHFS so far, and I haven't done any digging to see where the fault lies, but a dropped connection (either a dropped internet connection or an SSH session the server drops) really confuses the system. Messing about, I killed my internet connection during a read, and Finder hung until my the connection was restored. Another time, my session was killed for idleness by our server; when I tried to perform a read through Terminal, both Terminal and Finder crashed and took all of OS X with them.

  • The Man is King! (Score:1)

    by KaeloDest ( 220375 ) on Wednesday January 17, 2007 @08:20AM (#17644356)
    Sounds less stupid than Sing is King!... But if you have been to his site in the last three years he really has more Raw understanding of the Mac, and incidentally just about every other OS that you have never heard of. Undoubtably he is the pulse of a new mac future.

              macFuse... Now that I will reserve judgement on. I am sure that it works at least a little, in the same way that HFS and NTFS were based on OS 2\Warp's HPFS, but having R\W support means I can now fix any ailing NTFS drive in my shop-- Typically I will get a drive in and the dell or HP that it was on will report the drive as dead, and it wont boot for a variety of reasons, I will plug it into a Mac an recover all of the data... Definately gonna use it.

  • Super, I'm running to install it! (Score:1)

    by Optali ( 809880 ) on Wednesday January 17, 2007 @09:05AM (#17644702) Homepage
    That's exactly the feature I expected This has always been a great concern for me, as I have no available Linux box at work. But now I am finally empowered to completely fuck up my NFTS partition and ruin gygabytes fo data and months of work from both, work and home. I love it! The perfect complement to NTFS' own native goodness!

  • How about ext3? (Score:5, Interesting)

    by MMC Monster ( 602931 ) on Wednesday January 17, 2007 @09:27AM (#17644848)
    How about ext3 support on Intel macs? I tried the sourceforge project about a year ago and it didn't work.

  • genneral problem with FUSE (Score:3, Interesting)

    by hswerdfe ( 569925 ) <slashdot.org@nOS ... d.swerdfeger.com> on Wednesday January 17, 2007 @10:46AM (#17646028) Homepage Journal
    I love fuse it makes so many things so much easier.
    mainly I use "sshfs". but the biggest problem I have is the same problem I have with KDE-IOSlaves.
    is that you can't really chain them

    It makes it easy to Open a Zip/Rar file as a folder, and it makes it easy to treat an FTP server as a folder. but what about a Zip File on an FTP server?

    I just wish there was some easy way to allow the FTP/SSH file systems to recognize that a Zip File as folder.

    or chain to Zip with Encryption.
    or Encryption with Subversion.
    all at the file system level.
    any way thats my rant, but the FUSE effort is brilliant in general.

    • Re:genneral problem with FUSE (Score:2)

      by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Wednesday January 17, 2007 @03:57PM (#17651136)
      It makes it easy to Open a Zip/Rar file as a folder, and it makes it easy to treat an FTP server as a folder. but what about a Zip File on an FTP server?

      Mount the FTP server as a file system. Once you've done that, you now have, in your file system name space, a Zip file. Mount that Zip file. References to it, or the files in it, will be passed to the user-space zipfs, which will do I/O to the Zip file. That I/O will be passed to the user-space ftpfs, which will do FTP operations to get the file's contents.

  • Cocoa Fuse GUI (Score:5, Interesting)

    by mgorbach228 ( 938559 ) on Wednesday January 17, 2007 @01:07PM (#17648348)
    I'm working on a Cocoa GUI for FUSE (currently called MacFusion). The idea is that it loads plugins for supported filesystems (working right now on SSHFS, NTFS-3G and FTPFS at first). The plugins provide a configuration interface and code to mount/unmount. I'm hoping that this GUI will make FUSE goodness easily accessible to non-technical non-console people. In the future, it should be simple to support encfs, gmailfs, etc. This will be a FOSS project once a first build is ready. Anyone who wants to help is welcome, as are suggestions of any kind on the features/interface.

  • Tried it and comments (Score:4, Interesting)

    by Midnight Thunder ( 17205 ) on Wednesday January 17, 2007 @01:58PM (#17649204) Homepage Journal
    On reading about this I decided to install it on my Mac and see what it gives. While a great advancement, this is still a work in progress and still very much something for people familiar with the command line. The aspect that would change all this the ability to use FUSE based FS URLs in the Finder ( known issue [google.com] ), though this seems to be a limitation based on some private APIs needing to be made public, which I hope Apple resolves.

    • Re:Tried it and comments (Score:2)

      by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Wednesday January 17, 2007 @03:52PM (#17651050)
      ...though this seems to be a limitation based on some private APIs needing to be made public, which I hope Apple resolves.

      To be precise, it's a limitation on a private plugin interface needing to be made public. Making an interface public means committing to the interface, making it harder to make changes if a design decision made at time T turns out not to have been the right thing to do at time T plus delta T. (That particular interface might well change very significantly in future releases. It might be "done" at some point in the future, at which point Apple might decide to make it public.)

  • use ZFS to measure the overhead (Score:2)

    by r00t ( 33219 ) on Thursday January 18, 2007 @12:01AM (#17658580) Journal
    There is ZFS for FUSE, and the next MacOS X will have ZFS native. Compare them.

  • This will be nice for those without admin rights (Score:2)

    by theurge14 ( 820596 ) * on Friday January 19, 2007 @06:07PM (#17688274)
    At work we have Windows 2000 workstations locked down to where we are not able to install anything. This is good, but it leaves us no choice but to use USB key drives and portable apps if we want to run things like Firefox.

    I have an iPod formatted for Mac and YamiPod won't read it on those Windows 2000 machines, and I have no option of installing something like MacDrive on the machine to do so.

    Perhaps I could use something like FUSE.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close