FUSE Port Brings NTFS Support To OS X 150
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."
GmailFS also (Score:5, Informative)
FUSE for Windows (Score:5, Interesting)
Re: (Score:2)
Re:FUSE for Windows (Score:5, Interesting)
Release is FAAAAAAAAR away now, I expect to get something working in 3-4 months.
Re:FUSE for Windows (Score:4, Informative)
Re: (Score:2)
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.
Re:FUSE for Windows (Score:5, Funny)
If there's no fork, then how do you eat your meat (and consequently get the pudding)?
Re: (Score:3, Funny)
Re: (Score:2)
Obviously fingers won't work...
Re:FUSE for Windows (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
Stay away from the Windows.
Re: (Score:1)
"there's no fork() in Windows"
LOL, that's like "There's only one F in Fulham [wikipedia.org]"
.
Re:FUSE for Windows (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.
there must be a fork() for Windows (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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-
Re: (Score:2)
Re: (Score:2)
(because there's no fork() in Windows).
There is only the matrix.
Welcome to the dessert of the real. Tasty.
Re: (Score:1)
I have been thinking about making a FUSE filesystem for Linux and having it on Windows as well would be a great advantage.
Re: (Score:2)
I hope to have my very own Slashdot story when I finish porting
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Here's the project page http://cvs2svn.tigris.org/ [tigris.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:2)
The subject said "FUSE for Windows". Check out FUSE, do the math.
Re:FUSE for Windows (Score:5, Informative)
So with FUSE ported, Windows users can also enjoy in-filesystem versioning, seamless ssh integration, RAR files as folders and so on.
Re:FUSE for Windows (Score:5, Interesting)
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
Take Care...
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
[...] 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 l
Re: (Score:2)
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 availabl
Re: (Score:2)
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 comp
Re: (Score:2)
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
Re: (Score:2)
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
Re:FUSE for Windows (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
The IFS kit is now $109 [microsoft.com] and its documentation is now available online [microsoft.com], including a design guide. The only thing about it is that the IFS docs concentrate on file system filte
The creator of FUSE... (Score:5, Informative)
Re:The creator of FUSE... (Score:4, 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.
Re: (Score:2)
Thankyou, thankyou. Try the chicken, I'll be here all week.
Re: (Score:3, Informative)
Re: (Score:2)
Precompiled read/write NTFS packages (Score:5, Informative)
Re: (Score:1, Informative)
Great for dual booting? (Score:3, Interesting)
Re: (Score:3, Informative)
Great News! (Score:3, Insightful)
Re: (Score:3, Informative)
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: (Score:2)
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", i
Re: (Score:2)
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.
Re: (Score:2)
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 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!
Re: (Score:2)
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
Re: (Score:2)
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
Doh. mount_ntfs is already there (Score:2, Informative)
# which mount_ntfs
Re:Doh. mount_ntfs is already there (Score:5, Informative)
Re: (Score:2)
Gee, which is pretty much what most people use it for...
Re: (Score:3, Informative)
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 o
Great! (Score:3, Informative)
Thanks Google, you did us OS X users a great favorite!
Stability: SSHFS or MacFUSE at fault? (Score:3, Interesting)
The Man is King! (Score:1)
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 ai
Re: (Score:1)
Super, I'm running to install it! (Score:1)
How about ext3? (Score:5, Interesting)
genneral problem with FUSE (Score:3, Interesting)
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: (Score:2)
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 con
Cocoa Fuse GUI (Score:5, Interesting)
Tried it and comments (Score:4, Interesting)
Re: (Score:2)
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
use ZFS to measure the overhead (Score:2)
This will be nice for those without admin rights (Score:2)
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.
Comment removed (Score:5, Informative)
Re:FUSE? (Score:5, Informative)
Not quite... (Score:2)
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
Re:FUSE? (Score:5, Informative)
Try http://fuse.sourceforge.net/ [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.
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
That's the problem. (Score:4, Informative)
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:// [kde.org]) is darned slick, and I've always thought that Apple was missing out by not having something like it.
Re: (Score:2)
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)?
Re: (Score:3, Informative)
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 [ubuntu.com].
So if the server you're connecting to supports SFTP, and you're only going to be doing file transfe
Re: (Score:3, Informative)
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.
Performance? (Score:2)
Re: (Score:1)
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.
Re: (Score:3, Funny)
Um... maybe by "last I checked" you mean the 1990s?
Re: (Score:2, Informative)
Re: (Score:2, Informative)
Job done. It even tells you where to point your windows pc to.
Re: (Score:1)
http://www.apple.com/macosx/features/windows/ [apple.com]
http://www.apple.com/macosx/features/websharing/ [apple.com]
http://www.apple.com/pr/library/2003/jun/23server. html [apple.com]
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.
Re: (Score:2)
Re: Macs Do Speak Windows (Score:3, Informative)
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-
Re: (Score:2)
Re:good (Score:4, Funny)
Next time I'm buying the Commodore 128 or something else that can run GEOS!
Re: (Score:2, Informative)
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/ [dunkels.com]
Re: (Score:3, Insightful)
- 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.