Finally Linux has got
full read-write open source NTFS support! Preliminary benchmarks show that the still unoptimized driver already sometimes twice as fast as ext3 and 20-50 faster than the commercial Paragon NTFS. Interestingly Captive NTFS, which uses the native Windows NTFS driver, fails all benchmarks with file loss.
NTFS-3G: Full Read-Write Open Source Linux NTFS Driver
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Finally, something i am sure a lot of people where waiting for.
It looks to be just a tad rough arround the edges, but definatly stable enough to try out, something i will do shortly
This one just made my day, week and month; and a happier man too!
Umm..if this works I will switch to Linux, I swear, I just have too much data to delete it all. As the first poster said this could make my year.
I had a really bad experience with “captive ntfs”
I seem to be kind of slow at 4 am and after a birthday party, because only after trying it a couple of times without any luck i finally found the source of the problem, on a 64-bit system:
“Problem: Why doesn’t the driver work on 64-bit and bigendian systems?
Answer: We have no resource for that. Neither hardware, nor workforce.
Status: Low priority.”
Tough luck…
Yeah, that alone makes this worthless to me, at least for now. It’s one thing to have userspace programs 32-bit only (Flash plugin comes to mind…), but a kernel driver that’s 32-bit only? There’s not much way around that…
“Yeah, that alone makes this worthless to me, at least for now. It’s one thing to have userspace programs 32-bit only (Flash plugin comes to mind…), but a kernel driver that’s 32-bit only? There’s not much way around that…”
As i said, this is NOT a kernel driver – it’s userspace using FUSE.
FUSE or not, this is a major hurdle that needs to be overcome. There is a big difference between a FUSE driver that will be handling file system data and a flash plugin.
FUSE or not, this is a major hurdle that needs to be overcome. There is a big difference between a FUSE driver that will be handling file system data and a flash plugin.
Yeah, you’re right (but not the way you inteded to be). We don’t have the source for flash. Flash 64-bit would probably exist now for a long time already if people would have access to its source.
Linux-NTFS? Well, everybody can access the source and hack on it. It is an open road. If you need it and you can code, it is in your interests to help.
A big difference between those two, indeed.
Give the Gnash fellas a break, they’re working hard already
— a happy user able to watch badgerbadgerbadger with 64bit Gnash.
But that doesn’t really matter, since you still can’t work around it like 100% userspace programs (ie: a 32-bit chroot, or cross-compiled 32-bit binaries).
“We have no resource for that. Neither hardware, nor workforce.”
So lets give them a 64bit machine and ask them nicely
Well, I’m pretty sure that when the 32 bit version is stabilized, the 64 bit version will follow soon. Indeed, as first poster says, this is something a *lot* of people were waiting for. So be sure that a lot of people and companies will help the project
It works in userspace, not in the kernel
Edited 2006-07-15 10:10
I am a little bit afraid of a driver that does not yet support 64-bit systems.
By no means do I claim to be an expert at file system drivers, but to me that means poor implementation. I have written a few “drivers” for simpler, but still complex, filesystems and I had to pay very close attention to word size. Also, any decent kernel developer should be aware of coding practices for word size as well.
I understand the lack of testing ability, but I just hope that it is only minor problems. Hopefully the problems are worked out quickly and the driver comes out of Beta status.
Edited 2006-07-15 05:27
Looks like pretty minor issues. Someone said they tested it on a AMD64 and it worked fine, but they might not have stress tested it completely. Also, the endian issues can supposedly be fixed pretty quickly by creating getters and setters for the metadata.
A bit disappointed here too. This kind of attitude from a vast majority of open source developers (64-bit? Why, what is the big deal?) is kind of driving me away from open source. All the AMD based new computers and an increasing number of Intel based ones come now with a 64-bit CPU. Why should I run my 64-bit, dual core CPU in 32-bit mode?
Does open source only follow suit the inroads made by proprietary operating systems?
Sorry, a rather “disappointed penguin”
I’m not quite sure why you’d target the Open Source developers for the attitude that 64-bit isn’t a big deal, considering there were 64-bit versions of Linux and other Open Source Operating Systems long before Windows came out for 64-bit. Currently the OSS *nixes are better supported on 64-bit anyhow.
I do agree with most of what you say though, there should be more 64-bit software out there. The sad thing is, a lot of the copy protection methods these days won’t allow the game to work in 64-bit Windows, simply due to the copy protections not being ported to it.
Why would you say that it follows the inroads made by Proprietary Operating Systems, as I already said, 64-bit versions for Linux were out long before XP x64 was out.
True, SUSE (for instance) began supporting 64-bit before anybody else. But if you perform a search of 64-bit distros at Distrowatch, you’ll find that only about 10% of all available ones (including the *BSD based ones) support 64-bit computing.
That keeps me away from some very nice ones, like Blag or PC-BSD.
Even my beloved Kanotix and Debian still don’t fully support 64-bit (the last Kanotix one was a “Lite” version released in December. As to Debian the Netinstaller is broken)
A bit disappointed here too. This kind of attitude from a vast majority of open source developers (64-bit? Why, what is the big deal?) is kind of driving me away from open source.
Does open source only follow suit the inroads made by proprietary operating systems?
Sorry, a rather “disappointed penguin”
I don’t think it’s an attitude problem… more likely it’s a $$$ problem. Those developers doesn’t own a 64-bit computer! (accepting donations, though 😉 “Big company” does, but not many customers do (yet).
And that’s how both open source and proprietary can (sometimes) suck, in different ways and for different reasons.
“I don’t think it’s an attitude problem… more likely it’s a $$$ problem.”
And yet a basic AMD 64-bit is one of the cheapest and best value for money CPUs you can buy…
Not everyone can afford new hardware whenever they want to, especially when the old hardware works fine and does what they need to do.
Why would you need to delete? Safe NTFS read support has existed for a long time. Just copy everything to a nice ext3 disk and you’re done.
I really hope you are joking. Though I am perfectly fine with ext3, I don’t think everyone is. If someone is dual booting between Linux and Windows, currently the only way to share data between them is with the aging FAT32. Who in his right mind would use FAT32 to store sensitive data?
The other alternatives are to use an ext3 driver for Windows, which is a real pain to get working, or to hope for a decent NTFS driver in Linux.
Once this is in the kernel, this will be a HUGE barrier overcome for new users migrating to Linux. Now here is a question, does it support the version of NTFS with all of the metadata etc in the upcoming Windows Vista? That will take a common argument away from opposition to Linux on the Desktop.
“Once this is in the kernel, this will be a HUGE barrier overcome for new users migrating to Linux.”
The ntfs-3g driver won’t be in the kernel – it is using FUSE (Filesystem in Userspace, added to the mainline kernel since 2.6.14).
Wouldn’t it be better if the enhancements where ported to the kernel driver?
The reason this guy(s) are working with FUSE, userspace drivers, is to accelerate and ease development. After all, the reason we didn’t have R/W NTFS support so far wasn’t because of the quality of code, but because of lack of knowledge about NTFS internals. Some (more) experimenting/reverse engineering was needed.
So, if this approach proves succesful, I’m sure we’ll have a kernel driver some time in the future (years probably…), once the details about NTFS are clear.
Anyway, these are very, very good news and a very important step for Linux… I can’t wait to try it (once it stabilizes a bit)
I’ve just compiled it and installed it. No problems at all *cross fingers*. I am looking forward to benchmark it too. I am wondering how efficient it will prove. I know that the kernel ntfs-module has more going for it performance wise, but still, if the ntfs-3g proves good enough for intensive I/O it would be very very good news. I am wondering if one can play games like WoW directly from the windows drives with wine/cedega. These games are quite I/O intensive and stuff. You may say I am going looking for trouble – and I agree completely. But it’s just so irresistable to check the driver’s stability this way. Oh, and one more thing: Since ntfs-3g `got it down’ with the algorithms of writting to ntfs-partitions I bet that it will be very easy and it won’t take long to migrate code and concepts to the ntfs-module – which is awesome too.
I am wondering if one can play games like WoW directly from the windows drives with wine/cedega. These games are quite I/O intensive and stuff. You may say I am going looking for trouble – and I agree completely.
Just remember to report your experience when your NTFS partition turns into smashed potatos – thanks for doing beta testing 😉
This is great news, but bittersweet.
Because of the numerous patent issues that still surround NTFS, many distributions will probably still not include this. Specifically, I would guess that the Fedora project, and possibly the Ubuntu project, will not include this by default.
Indeed, but take heart that the two mentioned distro’s make it remarkably easy to install the driver.
Wow, I’m surprised that captive failed the benchmarks. I didn’t do any extensive testing but I did use it once or twice and was able to copy a file without corruption.
Aside from that, this is really great news. Linux recovery cd’s for Windows just got better
Well I tested captive once or twice. I’ve never got data corruption but I’ve never managed to use captive to scan all the files on a ntfs partition without a crash, so …
Has there been an attempt to have an distro use NTFS as its default filesystem? give that it is POSIX compliant etc. I don’t see why it couldn’t be achieveable.
Honestly why would anybody want to do that? NTFS is copyrighted and probably patentent by MS, so I doubt that you’öö ever see any distro using NTFS – especially when there are much better open source file systems like Ext3, Reiser, XFS etc.
Tom
Honestly why would anybody want to do that? NTFS is copyrighted and probably patentent by MS, so I doubt that you’öö ever see any distro using NTFS – especially when there are much better open source file systems like Ext3, Reiser, XFS etc.
I would hardly call ext3fs better than NTFS; ext3fs is nothing more than a really bad joke, maintained by those unwilling to admit that there are better alternatives out there, from the conservative JFS to the bleeding edge that is ReiserFS v4. Personal opinion yes, but there is a time and a place to admit when a horse has been flogged to death, and time to move on; Sun acknowledge the end of shelf life that is UFS and developed ZFS as the successor, Linux need to do the same.
Quit trolling and get a clue please. If you would look at the actual numbers *instead* of spouting off, you would realize you are incorrect.
Numbers showing Reiser4 is a regression over Reiser3 and doesn’t much compare to ext3:
http://linuxgazette.net/122/TWDT.html#piszcz
A patch that speeds up ext3 up to 50% in some situations. I have seen about a 30% speedup on 5 of our Oracle servers at work:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=…
Hans Reiser being completely called on his BS publically on the Linux kernel Mailinglist how he altered the Reiser4 benchmarks page deceptively:
http://lkml.org/lkml/2004/8/27/70
Notice how Hans Reiser gives a totally busted response knowing he was caught in a lie. Also, I speak from experience as a Linux systems admin that works with ~100 SLES9 and some Unix Servers. Reiserfs eats itsself, ext3 is rock solid.
Try turning on dir_index on a large ext3 volume and then grab a -mm kernel with reiser4. If you benchmark the two, ext3 will win in most situations using bonnie++:
http://www.coker.com.au/bonnie++/
Even though this unfinished userspace driver performed twice as fast as ext3?
Because the filesystem and file size limits on NTFS are larger than on XFS. Other than that, no reason.
(And that problem should be nixed once NILFS gets into the kernel.)
For those of you who didn’t allready know:
The Linux-NTFS guys are also working on a Mac OS X version that will propably ship with Leopad (10.5). See http://article.gmane.org/gmane.linux.file-systems.ntfs.devel/2597 for details.
This project beats the pants off Paragon NTFS, and they deserve it. Why charge a measly $20 for a binary kernel module and a mount extension when your business model obviously relies on selling a full suite of NTFS administration tools for $150? The “cheap” versions of commercial OSS products should instead be free as in beer. Only then can they get the market share to drive demand for the premium version. Of course Paragon has the right to charge whatever they please, but obviously their business model failed.
I wonder if any third party commercial vendor could be succesful at selling binary kernel modules. Because they can never be included in the mainline kernel, it limits their market to commercial distributors willing to license them. The OSS community will inevitably try to develop an OSS alternative, and when they succeed, the market for the commercial binary module evaporates almost instantly. The usefulness of binary modules is pretty much limited to those built by the hardware vendors and distributed free as in beer (i.e. the Nvidia driver and others).
Write access to NTFS partitions are probably today’s biggest barrier in the adoption of linux by not-so-interested-in-IT people. Everyone who already convinced someone of giving a try to linux ran through this problem : People can still listen to their music, watch movies or read their documents, but they have to reboot each time they want to do anything else, which make linux quite useless unless you switch your partitions to a linux friendly-windows hostile format, meaning that you’ll have big trouble if you want to switch back to linux, and that definitely frighten most of them.
Now think of the future of LiveCDs :
– It could store you linux home directory somewhere in C:Documents and Settings~ so you keep your settings between sessions on the same computer
– It could find your cross platform apps settings (Mozilla thunderbird mailboxes for instance)
– Windows tree could be understood by distros, so that your music player will search your My Music directory.
– We could even imagine smarter applications that will recreate the Windows users under linux, mount your My Documents directory to /home/~, and then put everything beginning with a . in Application Data, so that you keep your windows style tree.
The first time one will boot linux on his computer, he will be able to do almost all the things he used to do using windows. The only reason I see to stick to windows will be the propriatery apps, which is not a big deal for most of them (except maybe office).
I admit we still aren’t there but it’s almost only packaging issues now, and I’m confident about distros to understand this as a major enhancement to their product.
I’m not sure if you’d be able to store your ~ within a NTFS partition!?
Tom
What you say!?
I said that I’m not sure if you can store your home directory within a NTFS partition. I don’t know how this works out with permissions, uid/gid things etc.
As I understand it, NTFS is capable of full UNIX-style permissions, and the newer, better alternative of Access Control Lists. Microsoft has just never been keen on anyone reverse-engineering it for use.
It’s also got some wierd but useful features like storing identical files in different folders as physically just one file on disk (sorta like hard links), until someone modifies one of them…
I think I’m getting this from the Wikipedia article, so take it with a grain of salt.
I think for now it cannot be done directly:
“The ntfs-3g driver is an open source, GPL licensed, third generation Linux NTFS driver for 32-bit, little-endian architectures which was implemented by the Linux-NTFS project. It provides full read-write access to NTFS, excluding access to encrypted files, writing compressed files, changing file ownership, access right.“
I always try to keep my data on another partition the OS. I’ve started using ext3 in XP for that (using Ext2 Installable File System For Windows from http://www.fs-driver.org/) and so far haven’t run into any troubles. So you can already share your data easily without having to resort to FAT32.
Yes I use this solution too but for people who aren’t planning to switch to linux but just to give it a try usually still have all their data on a NTFS partition and converting it seems a quite complicated thing just for a try.
This may seem good news, but I don’t think they’re that good. Why? With support for ntfs read/write on linux and mac OS X we are again giving microsoft the edge, and once again everyone will choose a microsoft filesystem because you can access it under linux, mac OS X, and windows.
Microsoft will win again, because now MORE and not less devices will use ntfs, and other os’s and devices may be left out in the cold.
So instead of using open and documented filesystems, a proprietary, undocumented and closed-source filesystem will now be used to share information between computers. Not that fat/fat32 is that better, but at least it’s fully known and documented.
Well, that’s your opinion but I don’t agree with you. Given that Microsoft has never played nicely with its competitors, I don’t see why that should change soon.
So, accept it or not, competitors have to catch up Microsoft, not the other way around.
You are right that ms won again.
but to be honest: I would realy like ntfs to become the next fat. it is a great fs with most of the modern features. we must get rid of fat asap. and imo ntfs is the only thing (besides befs) that can do it.
lets face it, reiser is to fragile, ext to basic, and xfs&co are just overkill.
You are right that ms won again.
but to be honest: I would realy like ntfs to become the next fat. it is a great fs with most of the modern features. we must get rid of fat asap. and imo ntfs is the only thing (besides befs) that can do it.
lets face it, reiser is to fragile, ext to basic, and xfs&co are just overkill.
An alternative could be either HFS+, which is opensource or ZFS, either via a port of the CDDL source code, or someone reimplementing it in a clean room re-implementation under GPL.
Seconding HFS+ here (odd, I was thinking about it only a couple of days ago)
then there must be free drivers for these filesystem (ZFS,HFS+ or anothr one) for win32.
More frankly, if ntfs drivers is shipped with the next macOX iteration, NTFS would become the de facto standard for file transfers (would you tell the adverage joe to download and install drivers to read you usb key and that he must have administrator right to do so ?).
> Microsoft will win again, because now MORE and not less
> devices will use ntfs, and other os’s and devices may
> be left out in the cold.
Why not? If NTFS is good as a file system (I don’t know how it compares to others) then it makes sense to use it as a de-facto standard. And I think this step means MS *losing* control over NTFS a bit. I don’t see how other OSes are left in the cold, since they can simply look at Linux how NTFS works and implement it too. Devices are independent of the whole issue anyway.
> So instead of using open and documented filesystems,
> a proprietary, undocumented and closed-source
> filesystem will now be used to share information
> between computers.
I expect NTFS to be documented very well. You just don’t have access to the documentation. This whole project is a step in the direction to make docs available to everyone. It also makes NTFS less proprietary, since MS has much less control over who uses it. Finally, a filesystem cannot be open sourced, or closed sourced. An implementation can be, and this one *is* open sourced.
..And so what? NTFS just happens to be the premier filesystem for Windows users, and it’s a really good aone as well, but the situation with Microsoft’s lack of interest in the development of drivers for alternate filesystems you’re either stuck developing for Windows to being able to access foreign filesystems or you develop the likes for Linux or any other system in mind…
This is not a bad thing for Linux or any other open source OS, since these OS’s already are the ones providing the alternative to Microsoft, thus giving people the oppertunity of not having to stick to Microsoft’s proprietary solutions…
Mmh I do not understand why Microsoft should win then, in my opinion it’s irrelevant for the manufacture if Linux can read/write ntfs for their devices.
I think the criteria what filesystem is used is not that linux can read/write it, but the speed, maximum file size, stability and so on.
Microsoft wins because they realize that they can continue to release closed source file systems. Sure, under most circumstances those criteria would be good. However, if you use Windows, that criteria drops down to NTFS or FAT32.
Yet another smart hungarian guy!
Aha! I knew this was too good to be true, look at the filename (ntfs-3g-20070714-BETA.tgz), its from one year into the future. This guy seems to be in possession of a time machine. Just look at the release notes too, he states there that he is going on a journey for a month now, obviously he is gonna try to go to the future again and retrieve a newer version of this software.
On a more serious note, the driver seems to work fine, although writing large files appears to cause a problem with writespeed (transferspeed = 1 / filesize²)
But that is probably just caused by this being an early version of the software. Great work guys! One of the big hurdles in the way of linux migration just dissapeard.
Edited 2006-07-15 09:45
A week ago my friend told me that a apple employee is working on a NTFS driver for the coming MacOS X 10.5.
He also told me, that the employee would release the driver to the open source community, too.
And now I’m reading it here, pretty cool!
(I hope this new NTFS Driver finds his way into the kernel)
apple helped???
From where do you get this idea? Check authors file.
(I hope this new NTFS Driver finds his way into the kernel)
Again, you hope wrong. It can’t get into kernel, it is userspace file system (FUSE). And it belongs in kernel just as much as you would park your car in the air above the roof.
my friend told me about that a week ago. We discussed about Mac OS X 10.5 and the new NTFS support.
My friend told me, that a apple employee wrote an NTFS driver for the upcoming Mac OS X, and that the employee would release this driver to linux, too!
And now I’m reading this story about a NTFS driver for linux so my first thought was what my friend told me.
You probably thought wrong.
This is a FUSE driver
http://fuse.sourceforge.net/wiki/index.php/OperatingSystems
OSX is not supported by FUSE. So I doubt, that Apple would work on something that won’t work on OSX.
And taken my long relationship (as customer) with Apple I only expect that if they will release something it will be:
– with a lot of salt and grain inside
– taken away if proven successful
– under some license not acceptable to the rest of the world (read this and learn how avahi was started)
http://mail.gnome.org/archives/desktop-devel-list/2005-September/ms…
(also learn from Darwin experience)
So in my case: best I could say to Apple offering something is “Stick it …” and avoid any distro that would start to include it (thanks god, not one I use would).
This may seem good news, but I don’t think they’re that good.
Comrade Knuckles is right. We must resist the temptation of Capitalist-Imperialist ways! I say, we close the borders and keep this NTFS decadence out!
Joe “Dualbooting” Doe scratches his head. Comrade Linus scratches his head as well.
🙂
Edited 2006-07-15 10:52
Well, it seems one can’t have an opinion without being called a communist.
I just said that ntfs read/write support is going to create another de-facto standard around a non-documented non-free format controlled by microsoft. But I am not opposed at all to ntfs read support, in fact what I think is that read support is more than welcome, and I use it in some of my pc’s.
But I think it’s just easy to start shooting around instead of joining in with your opinion like the rest of us.
But I think it’s just easy to start shooting around instead of joining in with your opinion like the rest of us.
I probably sounded a lot more rude than I thought, sorry for that. I happen to be in the camp that favours technology over idealism, and your opinion reminded me the case of Kororaa Live CD, GPL evangelists doing more harm than good (IMHO)
I don’t think that fully supporting NTFS will harm Linux and the open source world any more than Samba hurted it.
Anyway, a good quality, safe, complete R/W ext3 driver for Windows would work about as well for my needs. I know one is in the works, but I have read stories about filesystem corruption… it’s not there yet.
Anyway, a good quality, safe, complete R/W ext3 driver for Windows would work about as well for my needs. I know one is in the works, but I have read stories about filesystem corruption… it’s not there yet.
This last comment by you brought up something that’s bothered me for quite a while. I’ve always wondered why there has been rock-solid fat32 r/w support in Linux for many years despite fat32 being closed source (to my knowledge anyway), yet there is still not rock-solid ext3 r/w support in Windows despite ext3 being fully open source. I too would get more use out of a working ext3 driver for Windows than the reverse.
FAT32, like all other versions of FAT, is very primitive and easy to reverse engineer. It was designed for floppy drives, and in typical Microsoft fashion, fiddled with in order to make it work with larger drives. That’s why it has problems with fragmentation.
There is ext2 support for Windows NT or better.
http://www.fs-driver.org/
I understand what you’re saying, but the problem is, it’s ALREADY a de-facto standard. Nearly every computer system sold since 2002 has had Windows XP on it, and I’m willing to bet most of THEM are using NTFS.
Unless you have an issue with people no longer reformatting their hard drives with FAT32 just to dual-boot Linux (like I did) I don’t see this as a problem.
Now that Linux apparently has NTFS support, what they’ve done is plug an obvious hole in Linux. The average user doesn’t care that Windows can’t read Reiser3, HFS+ or XFS; what they care about and notice is that Linux (this ‘miracle’ OS) can’t even read their hard drive.
We’re talking about people who may want to switch, but have zero tolerance for anything going wrong. As stupid as this sounds, Desktop Linux has to beat Microsoft at its own game because that’s what the average person assumes a computer is.
And of course, since I fully expect Microsoft to continue to redefine the terms of the game to benefit themselves, I expect they’ll change the version of NTFS in Windows Vista so it won’t work as well/at all with this new driver. Then again, they pushed back WinFS so I don’t know what else they might have modified or updated.
I can get rid of those nasty fat partitions I used to transfer stuff between Linux and Windows.
On the other hand, I liked Linux not being able to muck with my massive porno stash.
~ == $HOME == /home/USERNAME
…won’t be getting an easy time of it until permissions mapping works smoothly. That could be a bit of a problem because the NT and Linux permissions models are fundamentally different:
NT – Allow/deny permissions defined for each user/group including system pseudo-accounts.
Linux – Allow/deny permissions for owner, owning group and ‘everyone else’. (I’ve always felt this was a strong advantage of NT.)
Flame-proofing disclaimer: IANAfileysytem-guru, and the above will no doubt be a gross oversimplification.
I can’t currently see how a consistent mapping can be achieved without making security rather loose. I do hope they manage it though, as I too crave the demise of FAT on my system.
On a different note, an interesting experiment would be to ‘merge’ Windows and Linux installs into a single partition, with the bootloader simply choosing which kernel to boot. Anyone wanna give that a try?
Even Linux has ACLs implemented via SELinux.
Of course I agree it’s not for the Joe Dual-Booting Doe.
Edit 1: BTW Grub won’t work with NTFS still. NTFS is still too immature on Linux and there’s not much chance that GRUB will support NTFS in the next two years.
Edit 2: It seems SELinux is not required for ACLs:
http://wiki.kaspersandberg.com/doku.php?id=howtos:acl
How to use ACLs on a compatible FS using the acl package.
Edited 2006-07-15 14:04
Ya I was kinda dimly aware that ACL implementations were out there, but I guess we agree that the mapping issue can’t be easily solved. I suppose you could simply have a big ACL that accommodated the users of both systems, but there’s a long way between theory and implementation.
Interesting point about GRUB – which part of the process depends on the FS? I use it for my dual-boot, but I thought the actual bootloader-code was all in the MBR so it pointed to the partition/filename to boot, and that was an FS-agnostic process. My ineptitude showing through I imagine, but I’d be keen to know more.
Sidenote: my last paragraph above might have implied that my current system (using FAT) *is* secure. Don’t worry, I am not that thick! My reasons for wanting rid of FAT are more of the ‘it’s a crap DOS fs with poor naming, big-file and hardware-preservation’ kind.
I don’t think you will be able to boot Linux off NTFS with GRUB.
See this http://en.wikipedia.org/wiki/GRUB#Supported_File_Systems
Grub supports chain loading and thats how Windows can get booted off NTFS.
It wont be able to load a kernel on an NTFS partition without modifications.
Edited 2006-07-15 15:13
NTFS supports Access Control Lists (ACL)
Linux (ext3, reiser, etc) support Posix standard Discretionary Access Control (DAC) and (within the last several years) newer versions also support Access Control Lists. Here is a gnome gui for ACL support:
http://rofi.pinchito.com/eiciel/
I have hoped for being able to actually create compressed files/folders on an NTFS partition under Linux. Too bad it is still not possible. And I probably won’t have much use for this ntfs-3g either as I had used ntfsmount (in ntfsprogs) before and I don’t even use NTFS at home. Though, from experience I can say that ntfsmount worked a whole lot faster and better than captive-ntfs. Well, gotta include ntfs-3g on my custom Gentoo Linux LiveCD now then =)
Mounting a ~ file might be the solution. You don’t deal with NTFS but with a ext3/reiserfs/XFS/whatever file system.
Last time I used the experimental, which was a default on Fedora, my windows partition would not run properly. File permissions were changed so even as the computer administrator under windows you could not access them rewquiring a rebuild. NTFS write is dodgy at best.
i guess that basicly what is needed is to allow for a user space program to send specialized signals to the graphics card that the kernel will forward without complaint and similar…
that’s how the x windows framebuffer drivers work now, in effect.
that makes me wonder why nvidia needs a custom kernel driver…
They’re not frame-buffer based, they’re graphic engine based.
There aren’t many devices any more that are actually FB based.
well that just left me confused, guess i have to go read up on this stuff.
Are there any plans for porting Fuse to Windows?
Sort of. There are Shell Namespace Extensions, which is what Gmail Drive[1] uses. As far as I can tell this does roughly the same thing as FUSE.
[1] http://viksoe.dk/code/gmail.htm
hum last time I tried “pc bsd” it mounted an ntfs partition r/w without notice and trashed it… 80go lost
so take care while mounting ntfs r/w at this time and make backups