Slashdot Mirror


FUSE Port Brings NTFS Support To OS X

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."

150 comments

  1. GmailFS also by Anonymous Coward · · Score: 5, Informative

    GmailFS should also now be easily supported on Mac OS X using MacFuse.

    1. Re:GmailFS also by Anonymous Coward · · Score: 0

      I have managed to use GMailFS on Mac OS X. You can check my page for details
      http://blog.macos.fr/ and try for yourself.

    2. Re:GmailFS also by Anonymous Coward · · Score: 0

      What about the VFS plug-in support built into Mac OS X already? For instance, the MFSLives plug-in lets a Mac OS X users read the original Macintosh File System, the predecessor to regular-old HFS. Seems like the perfect place to fuse Mac OS X with other filesystems.

  2. FUSE for Windows by Cyberax · · Score: 4, Interesting

    I'm writing FUSE for Windows at my spare time (not much of it, unfortunately). Is there anybody who's doing the same?

    1. Re:FUSE for Windows by j-pimp · · Score: 1

      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.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    2. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      I'm writing FUSE for Windows at my spare time (not much of it, unfortunately). Is there anybody who's doing the same?

      No.

    3. Re:FUSE for Windows by Cyberax · · Score: 4, Interesting

      Yes, if they don't use any Linux/Unix-specific features. User-space part of FUSE, however, will have be modified (because there's no fork() in Windows).

      Release is FAAAAAAAAR away now, I expect to get something working in 3-4 months.

    4. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      I'm willing to test when you feel reasonable it won't make my machine particularly unstable for windows.

      Your jokes suck!

    5. Re:FUSE for Windows by Tony+Hoyle · · Score: 3, Informative

      Filesystems in Windows are a different animal to what they are in other OS's.. *way* harder. If you ever checkout the ntfsd list you'll see how many odd cases you have to handle because people make this mistake almost daily (oddly enough most of them are trying to do encryption).

    6. Re:FUSE for Windows by dangitman · · Score: 4, Funny

      (because there's no fork() in Windows)

      If there's no fork, then how do you eat your meat (and consequently get the pudding)?

      --
      ... and then they built the supercollider.
    7. Re:FUSE for Windows by The+Grassy+Knoll · · Score: 1

      "there's no fork() in Windows"

      LOL, that's like "There's only one F in Fulham"

      .

      --
      They will never know the simple pleasure of a monkey knife fight
    8. Re:FUSE for Windows by WindowsIsForArseWipe · · Score: 0

      in that case you're forked

    9. Re:FUSE for Windows by Cyberax · · Score: 1

      Yes, I found that the hard way. Kernel-level interface for filesystems in Windows is %$#%$TY$@$&*^.

      I'm not going to cover all possible cases (particularly, I don't even want to try to replicate Unix behavior with deletion of open files). My current aim is to port sshfs and zipfs.

    10. Re:FUSE for Windows by Max+Romantschuk · · Score: 1

      surely you jest?

      1) There is no difference between userspace and kernal space on windows*
      2) windows already has NTFS in kernel space
      3) see 1 and 2 windows has NTFS in user space
      4) why reinvent the wheel?


      The subject said "FUSE for Windows". Check out FUSE, do the math.
      --
      .: Max Romantschuk :: http://max.romantschuk.fi/
    11. Re:FUSE for Windows by odie_q · · Score: 4, Informative

      FUSE is a general Filesystem-in-userspace driver, supporting a long list of filesystems.

      So with FUSE ported, Windows users can also enjoy in-filesystem versioning, seamless ssh integration, RAR files as folders and so on.

      --
      ...ceterum censeo Carthaginem esse delendam.
    12. Re:FUSE for Windows by raynet · · Score: 5, Informative

      Well, FUSE is not NTFS. FUSE allows you to write userspace filesystem modules via stable and fairly simple API. Thus if you had FUSE for Windows, you could add new filesystems to Windows with relative ease. Also you could port the same modules to Mac, Linux and BSD or vice versa.

      --
      - Raynet --> .
    13. Re:FUSE for Windows by Cyberax · · Score: 2, Funny

      Windows developers have to use threads and fibers:)

    14. Re:FUSE for Windows by MemoryDragon · · Score: 1

      Yes there is a difference, the kernel runs on ring 0, and some drivers like the graphics drivers do, some dont, they run on different protection levels, and some run on real userspace some run on a space between user and kernel. The main problem will come with limited user accounts being the default installation, then something like fuse will be heavens sent!

    15. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      Please add davfs2 to your goal. It would be so nice to have a DAV implementation on Windows that doesn't suck. W2k was fine, but I've had nothing but problems with XP when any authentication is enabled. It also fails to work when using TLS/SSL (W2K also).

      Thanks and good luck.

    16. Re:FUSE for Windows by thaig · · Score: 1

      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.

      --
      This is all just my personal opinion.
    17. Re:FUSE for Windows by Cyberax · · Score: 1

      Not yet, I'm slowly rewriting parts of ext2 driver for Windows. It's in my private SVN repository and I can't figure out how to upload it to Google.Code or SF.net without losing history.

      I hope to have my very own Slashdot story when I finish porting :)

    18. Re:FUSE for Windows by dal20402 · · Score: 5, Funny

      there's no fork() in Windows

      You don't need to stick a fork() in. It's easy to see that Windows is done.

    19. Re:FUSE for Windows by Anonymous Coward · · Score: 0
    20. Re:FUSE for Windows by wandazulu · · Score: 1

      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!

    21. Re:FUSE for Windows by Cyberax · · Score: 1

      Well, there's http://code.google.com/p/coplandppc/wiki/FuseHfsCo de so it may be possible one day.

    22. Re:FUSE for Windows by artifex2004 · · Score: 1
      If there's no fork, then how do you eat your meat (and consequently get the pudding)?


      Obviously fingers won't work...
    23. Re:FUSE for Windows by elfurbe · · Score: 1

      Or you could use XPlay from MediaFour (the folks that brought you MacDrive forever and three days ago) to do the same thing three years ago when the 2G was hot shit. Seriously, did you ever even bother to look? Did you know MacDrive or MacOpener existed? I kid you not, sir, you can read and write Mac formatted disks on your PC TODAY, right this very instant in fact. I have done these magiks myself. This would not be new technology, just a possibly free incarnation of it.

    24. Re:FUSE for Windows by wandazulu · · Score: 1

      Yes, I was aware they existed and I have used MacOpener in the past. It worked well and I was always happy with it; I was excited about a free alternative.

    25. Re:FUSE for Windows by Azarael · · Score: 1

      Maybe a sript like cvstosvn could be modified to do a full project(starting from ci #1) co and ci into the target repo? It might put a lot of traffic on target server, but I can't see why it couldn't work.

    26. Re:FUSE for Windows by Azarael · · Score: 1

      Correction, I meant cvs2svn
      Here's the project page http://cvs2svn.tigris.org/

    27. Re:FUSE for Windows by Cyberax · · Score: 1

      A fellow ./er told me that it's possible to use SVK to push changes from one repository to another. I'll try to do it during my next weekend.

    28. Re:FUSE for Windows by Foolhardy · · Score: 2, Interesting

      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 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.

    29. Re:FUSE for Windows by TheNetAvenger · · Score: 4, Interesting

      So with FUSE ported, Windows users can also enjoy in-filesystem versioning, seamless ssh integration, RAR files as folders and so on.

      Why is this such a great goal, when FS developers have been trying to meet the basic features of NTFS already...

      NTFS already does journalling, has file versioning (far beyond what any *nix FS does), encyrption, compression, and with Win32, zip and rar integration.

      The trick in writing a FS for Windows isn't so much a NT issue, but how Win32 see the FS and what it expects to be there. This can best be demonstrated with the Unix subsystem on Windows, or how NFS is handled.

      BTW, this is kind of a baited post to see how well people really do understand NTFS and also what they are trying to accomplish.

      For developers interested there are some good resources and help on writing FS for NT, like at: http://www.osronline.com/cf.cfm?PageURL=showlists. CFM?list=NTFSD

      Take Care...

    30. Re:FUSE for Windows by Azarael · · Score: 1

      Yeah, that looks like a handy tool as well. I'll have to bookmark that site for later.

    31. Re:FUSE for Windows by ProfessionalCookie · · Score: 3, Funny

      I only dream of a world with No Fork-in Windows

    32. Re:FUSE for Windows by Arcane_Rhino · · Score: 1
      YOU THERE! Behind the curtain...

      Stay away from the Windows.

    33. Re:FUSE for Windows by niXcamiC · · Score: 1
      (because there's no fork() in Windows).

      There is only the matrix.

      --
      Chances are any disscution on Slashdot will degrade into a flamewar about ID/Christianity within 14 posts.
    34. Re:FUSE for Windows by Cyberax · · Score: 1

      No, that implies that the world was _intelligently_ designed :)

    35. Re:FUSE for Windows by odie_q · · Score: 1

      I reckon you are probably just trolling, but for the benefit of other readers I will respond anyway. Now, I haven't used NTFS since v1.2 (NT4) and am not a developer, so I might be way off here.

      I am pretty sure NTFS does not support versioning, although it could of course be implemented in userspace by using reparse points. The standard *nix file systems don't do versioning either, by the way. Zip and RAR are not implemented in the file system, which means you cannot access zip files as directories from the command prompt, for example.

      In any case, I don't think you realize what FUSE is if you compare it to a filesystem, any filesystem. NTFS can be (and has been) implemented in FUSE. While NTFS is a feature rich and extensible filesystem, it is still just a file system. See my example of seamless ssh integration - hop into a FUSE directory and voilà! You are in a directory on another box connected via ssh. Check out that list I linked to and you'll get the picture.

      --
      ...ceterum censeo Carthaginem esse delendam.
    36. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      If there's no fork, then how do you eat your meat

      The answer may be found in:
      Henry Petroski's The Evolution of Useful Things

    37. Re:FUSE for Windows by teridon · · Score: 1

      Would using Microsoft Services for UNIX help you port it?

      --
      I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
    38. Re:FUSE for Windows by *SECADM · · Score: 1

      It sounds like a great idea. I am sure lots of people (including myself) are willing to help out. I personally am interested in implementing a R/W registry filesystem (hopefully in usermode, when you are finished), I think that would be really useful for solving a lot of windows deployment issues...

      good luck to you.

      --
      sure I'll have a sig.
    39. Re:FUSE for Windows by *SECADM · · Score: 1

      Just downloaded and tried your regfs, it looks good! I have always wanted to do this to make life easier. Congrats on the good job so far! A question: how do i read and write the values? I tried "type" and notepad but it says it can't find the files.

      Are you looking for people to contribute to the project? I am definitely interested.

      --
      sure I'll have a sig.
    40. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      "has file versioning (far beyond what any *nix FS does)"

      Too bad OpenVMS isn't UNIX. ZFS has this too btw.

      The encryption is pretty crap in NTFS. Inferior compared to say TrueCrypt. Plus, NTFS doesn't have plausible deniability.

      The rest of your troll remarks I cannot comment on.

    41. Re:FUSE for Windows by Anonymous Coward · · Score: 0

      Have you tried Stunneling the TLS/SSL traffic instead of using the native implementation?

    42. Re:FUSE for Windows by Listen+Up · · Score: 1

      NTFS is certainly not far beyond what any *nix FS can do. Sun has had incredible FS's for, what, decades? For example their latest FS is ZFS which is now an open source project. Apple is also projected to offer full commercial support for ZFS in the upcoming OS X 10.5. Windows NTFS is not even a breath in the same sentence as ZFS.

      And that's not even touching many Unix/Linux FS's including XFS, JFS, and ReiserFS which are all excellent FS architectures.

      Look at this link comparing all of the FS's available on multiple platforms to make a determination for yourself:
      Wikipedia

      Heck, even Mac OS Extended (HFS Plus) looks good compared to NTFS.

    43. Re:FUSE for Windows by Foolhardy · · Score: 1

      Hmmm, you seem to have discovered a very perplexing bug; I did fix a problem with parsing certain types of relative paths (the updated version is online), which fixed the file not found error, but left me with a new one:

      As far as I can tell, for both echo and type, cmd.exe is opening the value successfully, and then not doing anything with it... in fact, it seems to be forgetting about the file handle entirely, allowing it to leak. What's really perplexing is in the case of echo text>file, cmd.exe opens file successfully and does absolutely nothing else with it. I can't imagine what possible input regfs could be giving cmd.exe from a single successful open operation to make it abort silently.

      Notepad will not be able to read or write until memory mapping is supported in some form (it'll say "%1 is not a valid Win32 application" which is a Win32 oversimplification of STATUS_INVALID_FILE_FOR_SECTION(section meaning memory mapping)). Unfortunately, there really isn't a clean way to implement memory mapping because I can't lock registry data, and the registry itself doesn't support memory mapping. It's listed in regfs limitations. I've been testing mostly with wordpad and mspaint, which seem to work fine.

      Speaking of limitations, there are problems that may prevent regfs from ever being a good enough replacement for using the registry API directly in general usage. For one thing, registry value types don't have a good analogue in a filesystem, except file extensions which aren't a good idea to translate into value types because you can have multiple files with the same base name differing only in extension but you can't have multiple values with the same name differing only in type. As soon as an app tried to create two files with the same base name, it'd be rudely surprised to find that one had overwritten the other. Even so, there may be better ways to work around those problems that I haven't thought of.

      The only reason I can think of for echo and type to fail is that they try to memory map but silently fail to... although even then the memory manager should be sending a preliminary paged read (but isn't) like it does for notepad. I could definitely use help debugging the echo and type bug, if you're interested. Feel free to e-mail me. If there's enough interest, I'd be happy to move to SourceForge or Google Code.

    44. Re:FUSE for Windows by TheNetAvenger · · Score: 1

      Heck, even Mac OS Extended (HFS Plus) looks good compared to NTFS

      Ok, first you are basing the FS based just on this table, but even in doing that, do you HAVE ANY IDEA what the numbers in the columns mean?

      HFS is closer to FAT32 than even coming close to NTFS.

      I am not going to knock ZFS, but the features that put it past NTFS are PRETTY NEW in terms of featurs offered. NTFS is OLD, as in 1991 OLD. There were very few FSs back then that inherently did Unicode and also supported 16 Exbibytes of space.

      When comparing FS there is more than just bytes and storage limits though, there are things like performance, data reliability, and features like journalling, compression, encryption etc...

      You mention several really good FSs, and I'm not going to say NTFS is the world's greatest FS, but it truly isn't something to sneeze at either. You are forgetting it has been doing for many years things many of the FS you mention just started doing in the last couple of years.

    45. Re:FUSE for Windows by TheNetAvenger · · Score: 1

      I am pretty sure NTFS does not support versioning

      Um, you might want to look at Windows 2003 Server and Vista. Versioning does happen at the FS level and is completely NT subsystem agnostic.

      In any case, I don't think you realize what FUSE is if you compare it to a filesystem

      I actually do know what it was, that was not the question I asked or the reason I asked the question I did. There are several good reasons for FUSE technology, but I think there are also a lot of people that go goo-goo based on what it is, and many on't realize that some of what it is doing is already in OSes, hence the baited question.

    46. Re:FUSE for Windows by hemancuso · · Score: 1

      During the course of development of SftpDrive [www.sftpdrive.com], we learned how much harder it is to develop a NT based filesystem than a simple VFS. One of the biggest problems with Windows filesystem development is the sheer lack of good examples that explain what is going on. With VFS you have a well defined architecture that "makes sense." With a windows filesystem you have a variety of messages you respond to, that send you huge parameter blocks that ultimately decide what type of operation will be performed. None of the high level architecture is in any way documented, and up until recently the IFS kit costed a developer $1200 and only consisted of a HUGE header file, along with source to SMB, CDFS, and FAT. These sources are well documented, but do nothing to explain why a particular thing is set up the way it is. Look around for some open source windows filesystems... there are basically none, and certainly none that people are running. We took the road of implementing a a FUSE like interface for windows, with a full custom driver that communicates with a very nice service. One approach people sometimes take is to write a SMB loopback server in userland, and then use that as their filesystem driver. It's kind of a nightmare. Try the openafs client out sometime -- you won't go a day without it locking explorer or tanking some application. Kernel programming for windows is a nightmare. Looking through all the material at osronline.com is extremely helpful, those guys are geniuses. When it comes down to it, something like a filesystem really needs to be tooled and polished and have all the edge cases weeded out over time. It's particularly difficult because a filesystem can connect up with any application in the system and given what a wide variety of installations people have, replicating specific conditions is often near impossible. Black Magic Debugging. Enjoy writing FUSE for windows :) again-- http://www.sftpdrive.com/

    47. Re:FUSE for Windows by BorgCopyeditor · · Score: 1

      (because there's no fork() in Windows).

      There is only the matrix.

      Welcome to the dessert of the real. Tasty.

      --
      Shop as usual. And avoid panic buying.
    48. Re:FUSE for Windows by odie_q · · Score: 1

      [...] look at Windows 2003 Server and Vista. Versioning does happen at the FS level [...] Cool, I've missed that feature completely (I read up on it at Wikipedia just now). Just goes to show how extensible the system is, I guess. Now, I have always been impressed by NTFS, but saying "versioning far beyond any *nix filesystem" in a FUSE thread was just trolling (nothing wrong with that, of course).

      I used to long for proper versioning in the file system, but FUSE has shown that it can be handled beautifully in userspace. This means I can pick any underlying FS, retaining full compatability with legacy systems on a movable disk. And that's just one tiny example of what FUSE can do. It is some really nice technology, to be sure.
      --
      ...ceterum censeo Carthaginem esse delendam.
    49. Re:FUSE for Windows by Foolhardy · · Score: 1

      This page has a listing of some free/open windows drivers, including three for ext2, one FFS, ReiserFS, AFS, and two user-mode driver system frameworks. They also have a clean-room free ntifs.h, although I prefer a more ReactOS style environment, which includes FAT and CDFS drivers. For that matter, I'm about 70% into writing my own.

      The IFS kit is now $109 and its documentation is now available online, including a design guide. The only thing about it is that the IFS docs concentrate on file system filters, not full FS drivers. Even so, if you implement the major IRP functions one at a time (read, write, enum directory, etc: each of which is documented), it's really not bad. Some of the functions are complicated (moreso than a VFS FS) but writing regfs has gotten me to the point where I can see how it all fits together. I find the architecture very usable, if overly complex. I haven't had to put in any magic app-specific hacks (at least not yet) to get them to work, even for Explorer.

    50. Re:FUSE for Windows by Listen+Up · · Score: 1

      Ok, first you are basing the FS based just on this table, but even in doing that, do you HAVE ANY IDEA what the numbers in the columns mean?

      First, there are multiple tables in the Wikipedia link, if you use your mouse or keyboard and scroll down the page. Second, yes, I absolutely know what I am talking about. And unlike you, I provided extensive reference to back up my claims. You have provided absolutely nothing. Third, you originally claimed that NTFS was better than any *nix FS, but then provided no direct evidence to support your assertion. As well as the illogical backpedaling in your response to my post (ie. NTFS is old).

      The fact is that NTFS is actually the same age development-wise as many better FS's available in *nix OS's. Considering NTFS was last updated in approximately 2002, your age argument rings false. FYI, NTFS is currently in version 3.x with another upgrade coming with Vista.

      Look over all of the tables in the Wikipedia link, hopefully you will learn something.

      PS-The Wikipedia page contains links for all of the FS's that are listed on the page.

    51. Re:FUSE for Windows by Foolhardy · · Score: 1

      Since FUSE requires a UNIXy environment for the user mode filesystem modules, I would think that SFU would be quite useful for that. The main alternatives that I know of are to use Cygwin instead (which has its own problems) or re-implement enough of a UNIX environment to compile the required FS modules (which would be a lot of work). IDK how Cyberax was planning to do it, but SFU really is the best option IMO.

    52. Re:FUSE for Windows by TheNetAvenger · · Score: 1

      The fact is that NTFS is actually the same age development-wise as many better FS's available in *nix OS's. Considering NTFS was last updated in approximately 2002, your age argument rings false. FYI, NTFS is currently in version 3.x with another upgrade coming with Vista.


      This statement alone proves you are talking out your ass. If your knowledge is based just on the data figures from Wiki then no wonder you have NO FREAKING clue what you are you even spouting...

      Yes NTFS was updated over the years, but what where the updates? Oh, they added compression, and then they added encryption.

      Oh and BTW the Vista NTFS version HAS NOT CHANGED, symoblic links were in NTFS since Win2K, Vista just added the native commands to use them...

      Here you do some freaking research and stop trolling on crap you have no idea about.
      http://en.wikipedia.org/wiki/Ntfs

    53. Re:FUSE for Windows by Windows+I+look+throu · · Score: 1

      Now that IS the funniest response to Windows I've read in a long time. You my friend, just made me laugh, and more so because I didn't 'see' it instantly :-)

    54. Re:FUSE for Windows by GWBasic · · Score: 1
      Yes, if they don't use any Linux/Unix-specific features. User-space part of FUSE, however, will have be modified (because there's no fork() in Windows).

      Have you ever played with Cygwin? Back when I was in college, (about 5 years ago,) all of my assignments had to run on my school's Unix system. I would develop on Windows using my favorite IDE, and compile & run locally under Cygwin. When the program was complete, running it on the school's Unix system was a trivial matter.

      I think Cygwin has a Unix-style fork(), but I'm not 100% sure. I didn't know about Cygwin until after I programmed with fork(). (On a side note, after my experience with fork(), I thank Bill Gates every day I use threading in .Net.)

    55. Re:FUSE for Windows by ProfessionalCookie · · Score: 1

      You're welcome.

  3. FUSE? by true_hacker · · Score: 0, Redundant

    Can anone point out what 'FUSE' is? --- I know i am lazy, no need to state the obvious.

    1. Re:FUSE? by Ash-Fox · · Score: 4, Informative
      Can anone point out what 'FUSE' is?
      Runs filesystems in userspace.
      --
      Change is certain; progress is not obligatory.
    2. Re:FUSE? by Zontar+The+Mindless · · Score: 4, Informative
      Can anone point out what 'FUSE' is?---I know i am lazy, no need to state the obvious.


      Try http://fuse.sourceforge.net/ - basically, when I hear of an Open Source project I've not heard of before, I just go to "nameofprojectgoeshere.sourceforge.net", and (more often than not) there it is. And there it was. :)

      --
      Il n'y a pas de Planet B.
    3. Re:FUSE? by Anonymous Coward · · Score: 0
      Lazy? You're doing it the hard way. It would have taken you less time to type it into your Firefox Wikipedia Lookup Extension or your Google home page/Wikipedia widget than it did to post that comment.

      From http://en.wikipedia.org/wiki/Filesystem_in_Userspa ce:

      Filesystem in Userspace (FUSE) is a Free (GPL and LGPL'ed) Unix kernel module that allows non-privileged users to create their own file systems without the need to write any kernel code. This is achieved by running the file system code in user space, while the FUSE module only provides a "bridge" to the actual kernel interfaces. FUSE was officially merged into the mainstream Linux kernel tree in kernel version 2.6.14.

      FUSE is not limited to, but particularly useful for writing virtual file systems. As opposed to traditional filesystems which essentially save data to and retrieve data from disk, virtual filesystems do not actually store data themselves. They act as a view or translation of an existing filesystem or storage device. In principle, any resource available to FUSE implementation can be exported as a file system. See Examples for some of the possible applications.

      The FUSE system was originally part of the A Virtual Filesystem (AVFS) project, but has since split off into its own project on SourceForge.

      FUSE is also available on FreeBSD, OpenSolaris, and Mac OS X.

      And from http://en.wikipedia.org/wiki/Ntfs-3g

      NTFS-3G is an open source, freely available NTFS driver for Linux. Unlike the NTFS driver included in the Linux kernel, its support for writing files has very little limitations: files of any size can be created, renamed or deleted on NTFS partitions, with the exception of compressed and encrypted files. ntfs-3g cannot yet modify Access control lists and permissions. NTFS partitions are mounted using the "FUSE" userland file system framework.

      NTFS-3G is free software licensed under the terms of the GNU General Public License.


      There you go.
    4. Re:FUSE? by Paulrothrock · · Score: 4, Informative

      I saw that definition when I first heard about FUSE and thought "Okay, so what's userspace?" For those who don't know: Userspace is the thing you're using right now. Rather than having the filesystem buried down deep in the bowels of the system, FUSE puts it above most of the stuff the OS does. That way, you can tell the OS things like "See those collection of Gmail messages to myself or RAR files or tarballs? That's a filesystem. You can move stuff onto and off of it just like another disk." FUSE is an easy, open source way of writing things that use unconventional storage methods for files.

      --
      I'm in the hole of the broadband donut.
    5. Re:FUSE? by AKAImBatman · · Score: 1

      In layman's terms, FUSE is an operating system driver that allows you to use a regular application as a file system driver. i.e. Instead of installing a special kernel module or DLL file, you simply run an application. Since you can pass parameters to that application, it becomes ideal for tasks like mounting ZIP files or SMB shares. Basically, stuff that's very transient and could otherwise crash your system. In the case of FUSE, your system is protected against a crash in the same way it's protected against any application crash.

    6. Re:FUSE? by mehemiah · · Score: 2, Informative

      that's just the linux version. The Mac version is hosted by googleCode and its probibly going to be on the first page for a while, otherwise just search for macFuse.

    7. Re:FUSE? by Anonymous Coward · · Score: 1, Interesting

      Additionally: if you link it into your application's address space, filesystem operations become zero-copy "for free". Multithreaded drivers are also a snap, and don't cause priority inversion problems for everything else, only consumers of the filesystem.

      Hmm, maybe there is something to that whole microkernel thing, eh Linus?

    8. Re:FUSE? by Midnight+Thunder · · Score: 1

      The other alternative is http://www.freshmeat.net/

      --
      Jumpstart the tartan drive.
  4. The creator of FUSE... by little1973 · · Score: 4, Informative

    ...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.

    --
    Government cannot make man richer, but it can make him poorer. - Ludwig von Mises
    1. Re:The creator of FUSE... by TeknoHog · · Score: 3, Funny

      So, FUSE will now fuse with SUSE?-)

      But seriously, I wonder how this relates to the SUSE-Novell-Microsoft connections... That's a nice implementation of NTFS you got there. It would be a shame if something happened to it.

      --
      Escher was the first MC and Giger invented the HR department.
    2. Re:The creator of FUSE... by hachete · · Score: 1

      so will SUSE abuse FUSE and loose it's users?

      Thankyou, thankyou. Try the chicken, I'll be here all week.

      --
      Patriotism is a virtue of the vicious
    3. Re:The creator of FUSE... by kobaz · · Score: 2, Informative

      You did great up until you misspelled lose :(

      --

      The goal of computer science is to build something that will last at least until we've finished building it.
    4. Re:The creator of FUSE... by kb · · Score: 1

      It's "loosen". Though they should take care at SUSE that they don't loosen their FUSE users too much because there's the danger they could lose them ;)

  5. Precompiled read/write NTFS packages by irgu · · Score: 5, Informative

    The original NTFS-3G source code doesn't compile on Mac OS X without some changes but the MacFUSE and NTFS-3G precompiled packages are available from IUseThis.

    1. Re:Precompiled read/write NTFS packages by Anonymous Coward · · Score: 1, Informative
  6. Great for dual booting? by Max+Romantschuk · · Score: 2, Interesting

    Boot camp users, care to comment on the implications?

    --
    .: Max Romantschuk :: http://max.romantschuk.fi/
    1. Re:Great for dual booting? by LEgregius · · Score: 2, Informative

      I have bootcamp installed. I can already READ my ntfs partition from OS X. No write support. FUSE does have some write support, so that's handy. I may use it.

    2. Re:Great for dual booting? by stewbacca · · Score: 1

      I was curious about this as well. I couldn't get the article to open at work, so I can only surmise what it said from the comments thus far. My question is, will this allow me to read and write to my XP partition (can only read now), or will it allow me to access the XP partition over the network, without being booted up in XP mode?

    3. Re:Great for dual booting? by Haeleth · · Score: 1
      My question is, will this allow me to read and write to my XP partition (can only read now), or will it allow me to access the XP partition over the network, without being booted up in XP mode?
      It gives you full read/write access to NTFS. You simply mount your Windows partition just like any other drive. No network involved. It's stable and safe. There are some minor performance issues with very large files, but if you do stuff like movie editing you probably do that in OS X anyway, right?

      If you have Windows installed on the same computer as OS X, then you want this program, period.

      (Caveat: I'm a Linux user, so my usage of "simple" may not agree with yours...)
    4. Re:Great for dual booting? by stewbacca · · Score: 1

      Hey thanks for the info. I'll have to check when I get home, but my question about the partition is that the XP partition that mounts on my OS X desktop as "untitled" doesn't show up over the wireless network with my other two macs.

  7. Great News! by RAMMS+EIN · · Score: 2, Insightful

    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?

    --
    Please correct me if I got my facts wrong.
    1. Re:Great News! by jack_csk · · Score: 3, Informative

      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.

    2. Re:Great News! by SanityInAnarchy · · Score: 1

      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...

      --
      Don't thank God, thank a doctor!
    3. Re:Great News! by RAMMS+EIN · · Score: 1

      ``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.

      --
      Please correct me if I got my facts wrong.
    4. Re:Great News! by SanityInAnarchy · · Score: 1
      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!

      --
      Don't thank God, thank a doctor!
    5. Re:Great News! by RAMMS+EIN · · Score: 1

      ``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.

      --
      Please correct me if I got my facts wrong.
    6. Re:Great News! by SanityInAnarchy · · Score: 1

      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

      --
      Don't thank God, thank a doctor!
  8. Doh. mount_ntfs is already there by Tetard · · Score: 2, Informative

    I use it everyday...

    # which mount_ntfs /sbin/mount_ntfs

    1. Re:Doh. mount_ntfs is already there by irgu · · Score: 5, Informative

      Mount_ntfs doesn't have full read/write possibility. NTFS-3G has and it's commonly used on Linux.

    2. Re:Doh. mount_ntfs is already there by slamb · · Score: 2, Informative
      From the manpage, mount_ntfs(8) has significant limitations:
      There is limited writing ability. Limitations: file must be nonresident and must not contain any sparces (uninitialized areas); compressed files are also not supported.

      I can't seem to find a straight definition of "nonresident files" in the context of NTFS, but my best guess from glancing over google results is that "resident" files are ones which have their contents in a small block embedded in the inode itself. That'd be an optimization to minimize internal fragmentation on small files. If I'm right, a Windows-produced NTFS is likely to have a lot of these files. Not sure if OS X can't write to them at all, or if it will just make them non-resident when it does so.

  9. good by mastershake_phd · · Score: 0, Flamebait

    If there is one thing Ive had trouble with its getting Windows and Mac to talk to each other. External hard drives wont work from one to the other(last I checked), networking isnt possible(last I checked). Ive been forced to use CD-Rs in the past. Hopefully now I can use that external hard drive.

    1. Re:good by dasmoo · · Score: 1

      Uh, I dunno if you've used a Mac before, but I'm pretty sure that since OSX they've understood NTFS drives. Sure, no writing, but that's why you convert all your drives to HFS+. It reads Internal, External or Anal, whichever I chuck at it. Also, my windows machine seems to be able to handle the mac drives. As long as I'm using MacDrive (the application, not the drive itself)

    2. Re:good by Anonymous Coward · · Score: 0

      Err. I can sort of go along with the external HDD thing. As long as you don't want to use fat32, which both systems handle fine.

      Not sure how you can't get a win and mac machine to talk to each other on the network. I use samba/smb to transfer to all of my systems. That seems to work fine. Could also use ftp if you really had to.

      Unless you're talking os 9. I don't have the experience to comment on that.

    3. Re:good by Dekortage · · Score: 2, Funny

      Um... maybe by "last I checked" you mean the 1990s?

      --
      $nice = $webHosting + $domainNames + $sslCerts
    4. Re:good by henrikba · · Score: 2, Informative

      I usually recommend ext2 on external disks that are to be used seamlessly between windows/linux/mac environments. Works like a charm! Ref. http://sourceforge.net/projects/ext2fsx/ http://www.fs-driver.org/

    5. Re:good by Anonymous Coward · · Score: 2, Informative

      Just go to sharing in system preferences and click for enable windows sharing.

      Job done. It even tells you where to point your windows pc to.

    6. Re:good by CapnOats.com · · Score: 1

      Troll? What year is this?

      http://www.apple.com/macosx/features/windows/
      http://www.apple.com/macosx/features/websharing/
      http://www.apple.com/pr/library/2003/jun/23server. html

      That last one is a press release from June 2003 where they talk about Samba 3 in Mac OS X.

      Plus you could always format the ext. drive with FAT32 and pretty much every modern OS could access it.

      Hell, if you were that determined you could simply pipe dd through netcat and be done with it.

    7. Re:good by Undertaker43017 · · Score: 1

      I use MacDrive6 on my Windows boxes and format all of my external drives as HFS drives. Now I have fully read/write capability on OSX, Linux and Windows, without the limitations of FAT32. It isn't free, but it certainly makes life easier when moving external drives between different OS's.

    8. Re:good by MightyYar · · Score: 3, Funny

      The two worst-connected computers I currently use are my Mac Plus and my TRS-80. It seems like neither one will connect to Windows 3.0. I'm not even sure where I'm supposed to stick the ethernet thingy.

      Next time I'm buying the Commodore 128 or something else that can run GEOS!

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    9. Re:good by Slashcrap · · Score: 1

      Sure, no writing, but that's why you convert all your drives to HFS+.

      Good point! I'm converting all my NTFS drives as we speak. I assume that Windows will still be able to read from them afterwards or you would have mentioned it? I sure hope so!

      It reads Internal, External or Anal, whichever I chuck at it.

      I know that Apple tends to be associated with homosexuality, but I think you're taking things a bit too far.

    10. Re:good by CityZen · · Score: 2, Informative

      For the Mac Plus, there was a SCSIethernet box you could get. Pretty straightforward installation.

      For the TRS-80, your best bet may be running SLIP or PPP over a serial or parallel interface. Of course, viewing web pages in 128x64 block graphics might be something of a challenge.

      Fortunately, Commodore 64/128's have an ethernet solution available. See http://www.dunkels.com/adam/tfe/

  10. Great! by jack_csk · · Score: 3, Informative

    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!

  11. The Man is King! by KaeloDest · · Score: 1

    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.

    --
    --Shaddup and support your local PBS station Plan for it
    1. Re:The Man is King! by Anonymous Coward · · Score: 0

      OS/2 Warp's HPFS is the basis for Mac OS's HFS+? What parallel universe do you live in?

    2. Re:The Man is King! by jdp816 · · Score: 1

      What? HPFS came out in 1989. HFS came out in 1985. NTFS came out in 1993. Both HPFS and NTFS were projects that MS was involved in. HFS predates both by at least 4 years. Who copied what?

  12. Super, I'm running to install it! by Optali · · Score: 1

    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!

    --
    -- 29A the number of the Beast
    1. Re:Super, I'm running to install it! by niXcamiC · · Score: 1

      Are you trolling or being sarcastic?

      --
      Chances are any disscution on Slashdot will degrade into a flamewar about ID/Christianity within 14 posts.
    2. Re:Super, I'm running to install it! by Optali · · Score: 1

      No, just plain sadistic. You have a Linux box, you havve a Win box with NTFS, you are compiling the kernel and find this FUSE module, with a warning that says "Dangerous"... hmmm, what would you do? Leave it in peace? No way! Just thinking about the possibility of inflicting hours of pain and torture to the behated Win box, at least a fraction of the suffring it has caused you, will decide you that you definitely want this module, with the read and write option, all the deug option and of course; everything that has the label "Dangerous" and "Experimental" and warningas about potential damage, bwahahahaa }:E Seriously: Darn good work, I use it in SUSE and haven't had a problem till now.

      --
      -- 29A the number of the Beast
  13. Re: Macs Do Speak Windows by Telephone+Sanitizer · · Score: 3, Informative

    Macs running OS X have built-in Windows file sharing -- you can share files from the Mac and you can connect to Windows network-shares. Windows Active Directory and VPN might complicate things a bit, but offer no more problems from a Mac than they do from the average Windows PC.

    As for sharing an external hard drive, while Macs only read NTFS volumes, they can both read and write to FAT32 volumes which are compatible with Windows as well. There are, however, limitations to FAT32 such as the 2GB maximum file-size which might make that a less-than-optimum solution.

    Another alternative is to purchase a commercial product such as MacDrive, which allows Windows PC's to access hard drives that have been initialized with the Mac (HFS+) file system.

  14. How about ext3? by MMC+Monster · · Score: 4, Interesting

    How about ext3 support on Intel macs? I tried the sourceforge project about a year ago and it didn't work.

    --
    Help! I'm a slashdot refugee.
    1. Re:How about ext3? by Anonymous Coward · · Score: 0

      it works. ...
      kinda.

      for 10.3 everything 'works like a charm' (like someone has written here before)

      for 10.4: read only access is reliable.
      stay absent from the prefernce pane and use the terminal to mount the disk. to make the partition visible in the finder, etc. use cmd-shift-g and enter the mount point.

      for write access use the latest public development version by installing d3 and upgrading to d4 which can be found in the sourceforge forums. be warned about the write access, though: it's known to cause kernel panics. you need to e2fsck/fsck_ext2 after any such crash which takes a long long long time of the moment but rarely finds defects related to the crash. to avoid the panics unmount/remount often and make sure you don't re-access a file that has been tampered with before (since you last remounted that partition).

      there is a fuse implementation of ext2 aswell, you can find it here: http://www.kernel.org/git/?p=fs/fuse/fuse-ext2.git
      it's been developed as part of unionfs. unionfs again is reported to work with macfuse (at least that's what is written in the macfuse wiki). however, i found no reports of somone using or trying to use ext2 via macfuse, yet. it might be worth a look - i'm afraid i lack the skills for pioneering work.

      -losof

    2. Re:How about ext3? by Anonymous Coward · · Score: 0
      oh, and, it's all an implementation of ext2 which is like most people know here ext3 without the journaling part but back- and forth compatible.

      -losof

      sorry about the back- and forth ... ))<>(( bit me.
  15. Re: Macs Do Speak Windows by CastrTroy · · Score: 1

    Actually, the maximum file size on FAT32 is 4GB, but that's still pretty small.

    --

    Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
  16. genneral problem with FUSE by hswerdfe · · Score: 2, Interesting

    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.

    --
    --meh--
    1. Re:genneral problem with FUSE by Guy+Harris · · Score: 1
      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.

  17. That's the problem. by Kadin2048 · · Score: 3, Informative

    Sure, no writing, but that's why you convert all your drives to HFS+

    That's kind of a huge limitation. There are lots of times when you might want to share a drive back and forth between a Windows and Mac machine, and it's not possible or desirable to run MacDrive on the Windows side (and having for format the drive with FAT32 sucks mightily).

    Letting the Mac understand NTFS is a good thing, because it provides for more interoperability. The only downside to it, is that it might cause people to think of NTFS as a good inter-operable standard, rather than the disgusting, proprietary, Redmond Albatross that it is.

    Plus, being able to use SSH as a filesystem is pretty slick, and will probably get more use than the NTFS part. KDE's implementation of SSH-as-filesystem (called fish://) is darned slick, and I've always thought that Apple was missing out by not having something like it.

    --
    "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    1. Re:That's the problem. by EXMSFT · · Score: 0

      The only downside to it, is that it might cause people to think of NTFS as a good inter-operable standard, rather than the disgusting, proprietary, Redmond Albatross that it is.

      Wow. Tell us how you REALLY feel.

    2. Re:That's the problem. by hawaiian717 · · Score: 1
      KDE's implementation of SSH-as-filesystem (called fish:// [kde.org]) is darned slick

      Interesting, hadn't heard of this before and just tried it. Is there any advantage to using fish:// instead of sftp:// in Konqueror (aside from it might work with servers that have the SFTP subsystem disabled)?
      --
      End of Line.
    3. Re:That's the problem. by Guy+Harris · · Score: 2, Informative
      KDE's implementation of SSH-as-filesystem (called fish://) is darned slick, and I've always thought that Apple was missing out by not having something like it.

      FUSE isn't like it - in at least some ways, it's better. FUSE makes it work at the UN*X API level, which means that even non-KDE applications, such as grep, can use it.

    4. Re:That's the problem. by Kadin2048 · · Score: 2, Informative

      I think "works when SFTP won't" is the only other big advantage.

      I did some quick Googling on the subject of Fish versus SFTP, and apparently: "The fish kio...relies [only] on the ssh [server] providing a unix shell, then it uploads a simple server program written in perl. A beautiful hack and handy if sftp is not available on your ssh server, but nowhere near the performance or reliability of sftp." From here.

      So if the server you're connecting to supports SFTP, and you're only going to be doing file transfers, you might as well use it. But FISH will work even in situation were SFTP isn't supported, and your only way in is via SSH.

      --
      "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
    5. Re:That's the problem. by bensch128 · · Score: 1

      I'm a huge kde/kioslaves fan too but IMHO fuse is really the way to go.
      It'll allow all unix applications to access those interesting FSs in a common manner. The only problem is that the type (fish:,http:,ipod:,etc.) gets thrown out the window and mapping isn't as flexible as having a URI.
      But it makes more sense in the long run...

      Cheers
      Ben

  18. nt3gfs has no ACLs, so its virtually worthless by hildi · · Score: 0

    unless you are just storing data.

    1. Re:nt3gfs has no ACLs, so its virtually worthless by oddfox · · Score: 1

      "... just storing data."

      Gee, which is pretty much what most people use it for...

      --
      "We invented personal computing." - Bill Gates
  19. Cocoa Fuse GUI by mgorbach228 · · Score: 5, Interesting

    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.

  20. Re:Yet more Linux - OSX leeching by Anonymous Coward · · Score: 0

    I love it how stating a FACT (that OS X users/developers are leeches on the open source community, porting everything to OS X but giving nothing back) is moderated down as flamebait.

    Here's a clue, mods, if you want to win an argument, you need to present counter arguments, not just silence those you disagree with.

  21. Tried it and comments by Midnight+Thunder · · Score: 3, Interesting

    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 ), though this seems to be a limitation based on some private APIs needing to be made public, which I hope Apple resolves.

    --
    Jumpstart the tartan drive.
    1. Re:Tried it and comments by Guy+Harris · · Score: 1
      ...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.)

  22. Re:Yet more Linux - OSX leeching by Divebus · · Score: 0, Redundant

    Yeah, WTF is going on with the mods these days? For the last few weeks everything has been whacked. I've never seen anything as weird as (Score:0 Insightful) until recently. Things that are barely useful are +3 and anyone stating a fact might get -1 slapped on them. So, WTF? Over...

    --

    Most of the stuff on /. won't survive first contact with facts.
  23. Re:Yet more Linux - OSX leeching by sveinungkv · · Score: 1

    They have given something back. For example the first Free software RTP/RTSP streaming server was released by Apple.

    --
    Spelling/grammar nazis welcome (English is not my first language and I am trying to improve my spelling/grammar)
  24. Stability: SSHFS or MacFUSE at fault? by jdbartlett · · Score: 2, Interesting

    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.

  25. Google beat you to it? by Anonymous Coward · · Score: 0

    Just out of curiosity: any idea how the dev team created those iconic click-to-mount file systems shown off in the tech talk?

  26. Re:Yet more Linux - OSX leeching by Em+Adespoton · · Score: 1
    Bonjour comes to mind :)

    Now let's talk about Linux, and how it stole most of its OSS from HURD. Talk about a leech!

  27. Re:Yet more Linux - OSX leeching by moderators_are_w*nke · · Score: 2, Insightful

    If you're not flamebaiting then you probably want a serious answer. My guess is twofold:

    - Mac has a culture of charging small amounts of money for software released commercially rather than open sourcing things (e.g. TextMate). This dates to before the OSX days.

    - People writing code for Macs tend to use Cocoa because its the easiest way to do it and this doesn't port easily to other systems.

    --
    "XML is like violence. If it doesn't solve your problem, use more." - Anonymous Coward
  28. Binary installer for NTFS-3G by tigeba · · Score: 1

    I couldn't find a binary installer for NTFS-3G, so I whipped one up and made it available here. You need to install MacFUSE first. I will see if I can make a UB version this evening and test it on my G5. Enjoy, and let me know if there are any problems. It is tested (lightly) on a MacBook and MacBook Pro

  29. Not quite... by SanityInAnarchy · · Score: 1

    Yes, that is what you can do with FUSE, but you can also do that without FUSE. All FUSE is doing is making it much, much easier.

    FUSE is far from the only link from kernel space to userspace, and far from the only one where the kernel is coming to a userspace daemon with requests. For instance, udev is a system where the kernel tells the udev daemon about a new device, and the udev daemon looks in its config files and creates a device node (those files in /dev) -- this is what allows you to plug in a USB keychain device and expect it to work, or at least expect to be able to mount it right away.

    Basically, the kernel is the thing behind the thing you're using right now. To over-simplify, kernel is to OS what CPU is to PC. Most kernels are monolithic, meaning it's a single program -- more specifically, a single process. Linux (the kernel) is one gigantic, multi-threaded x86 process.

    Now, kernel programming is hard. Very hard. You basically have to program in C, but you get absolutely no libraries that aren't already in the kernel -- remember, most shared libraries are stored as files on a filesystem? Well, where does the filesystem get its libraries? So if you want a library in the kernel, you have to put it there -- which is pretty much like porting it.

    You also have pretty much no memory protection, as far as I know. You know, things that would segfault a normal program -- or "illegal operation" on Windows? It's the kernel that handles that. Basically, this means that if you end up with a pointer to some address you didn't mean it to, you'll be able to write there -- which means anything in the kernel can pretty much scribble all over anything in RAM, which means a bug in the kernel can screw up your system in absolutely any way imaginable, including file corruption. This is why we don't like the nVidia drivers, by the way -- they're binary, a black box, and sometimes they do have serious bugs, with serious consequences, including file corruption. Think of all the complaints people have had about Flash and Java crashing Firefox (admittedly not as much lately, but still), and imagine that's your entire OS, and you start to get the picture.

    So, even if your program is written entirely in C, there are many things you can't do in the kernel that you can do outside the kernel -- which means, userspace.

    So writing a filesystem in FUSE means you can use libgmail, you can write your filesystem in Perl or Python, you can call librar without having to teach the Kernel to understand RAR files...

    Generally, anything you can do with FUSE, you could theoretically do with something else, including doing it IN the kernel. You do it with something specialized, like, say, a specific API through which the kernel calls a program in userland which understands RAR files. You could even port librar to the kernel -- technically, you can actually do anything in the kernel, it's just harder. FUSE puts it in userspace, making it easy.

    And now it's portable, too. Remember, userspace isn't all that different between Unices -- often, you can make an initial port of a simple, commandline app from Linux to OS X simply by recompiling. So all those cute little filesystems people have been writing for Linux -- including ntfs3g, but also sshfs, gmailfs, all that other stuff -- those all work on OS X now, and the only people who had to deal with the OS X kernel are the FUSE team.

    The drawback is speed -- context switches. A context switch (for those who don't know) is what happens when you flip from executing userland code to kernel code, or vice versa -- and it takes a little bit of time. Everything you do is now automatically four context switches -- some app tries to access a file, so it asks the kernel to open that file. The kernel then talks to your FUSE daemon, so now the FUSE daemon is running. That's two already. Even if the daemon does nothing other than send "Hello, world!" back to the app, it has to send it back to the kernel, first... That's ignoring things like,

    --
    Don't thank God, thank a doctor!
  30. Performance? by SanityInAnarchy · · Score: 1

    It seems to me that kioslaves would be able to perform better than fuse ever could. Maybe the best solution would be some sort of glibc hack?

    --
    Don't thank God, thank a doctor!
    1. Re:Performance? by bensch128 · · Score: 1

      What makes you think that? AFAIK fuse is written in C (as a driver inside the kernel) and I would expect the plugin file systems to be written in C/C++ (although I know there is ruby and probably python bindings) Why should fuse be any slower then kioslaves.

      Cheers
      Ben

  31. there must be a fork() for Windows by r00t · · Score: 1

    How else would be POSIX subsystem and SFU subsystem run?

    Probably fork() is an obscure undocumented NT-native call. You just need to find it, call it, and hope that your C library doesn't go into convulsions.

    1. Re:there must be a fork() for Windows by Cyberax · · Score: 1

      No, it's possible to use native NT API to clone process. But it's slow and error-prone. FUSE userland doesn't really need fork(), it can do without it.

  32. use ZFS to measure the overhead by r00t · · Score: 1

    There is ZFS for FUSE, and the next MacOS X will have ZFS native. Compare them.

  33. TrueCrypt vs sshfs...for MacOSX (WinXP/Parallels) by DonZorro · · Score: 1

    I've been trying to get a decent way to encrypt my Parallels/WinXP drive/folder.

    MacOSX home folders using filevault a neat,
    but I have to keep the Parallels/WinXP folder in /Applications or some such thing...this makes my WinXP accessible by other users (eg. admin) on the same laptop.

    Any working suggestions?

  34. Re: Macs Do Speak Windows by Telephone+Sanitizer · · Score: 1

    4GB.

    Thanks. I mis-remembered. FAT16 has a 2GB limit.

  35. Re:Yet more Linux - OSX leeching by Anonymous Coward · · Score: 0

    Here's your counter argument. Apple has released WebKit and launchd to the open source community. Nokia uses WebKit for their S60 series phones and KHTML developers get back source code from any improvements Apple has made. You may get off your high and mighty horse now. You should be happy Apple is using open source code.

  36. This will be nice for those without admin rights by theurge14 · · Score: 1

    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.