Slashdot Mirror
Fully Open Source NTFS Support Under Linux
lord_rob the only on writes "The Linux NTFS project has released a beta version of its fully open source userspace (using FUSE) 3G-Linux NTFS support driver. According to the developer, this driver beats hands down other NTFS support solutions performance-wise (including commercial Paragon NTFS driver and also Captive NTFS, which is using windows ntfs.sys driver under WINE)." That's right, writing to NTFS even works. Soon it'll mean one less recovery disk to keep around, I hope.
This gives us another tool that can be used to repair windows systems that have been hit by some of the newest rootkits that can hide from detection when windows is running. Can't hide from a Linux boot disk and with complete write support, now these can be cleaned and studied more effectively.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Unless I missed it, I notice the performance numbers are only single process. I'm suspicious of this because user-mode filesystems (as under microkernel operation systems) typically crash and burn performance-wise under simultaneous load, not under single-user use.
I know that user-mode is easier to debug, but they really should turn this into a kernel module.
Sometimes it's best to just let stupid people be stupid.
Think of the implications:
A given distro can now come with a handy Windows InstallShield Wizard and INSTALL UNDER WINDOWS and BOOT/SHARE the same partition.
This is huge. Who wants to be the first to make a Linux ActiveX malware distro?
More
I think it's great that Linux has gotten this far with NTFS reading/writing reverse engineering. I've used the shaky NTFS support for quite a while. One key use is when you forget the Admin password on Windows, and you're either locked out of the system or have only user-level privileges, you can use a Linux bootdisk the open the (otherwise hidden) password file and blank it out. The NTFS drivers have always had dire warnings about writing to NTFS possibly resulting in corruption, so this step forward is great.
However, I think you're exactly right – one way or another, MS will find a way to tweak the filesystem, probably in Vista, maybe even as an auto-updated "security fix" to XP, that will make compatibility even harder. Look at how long it's taken us to get this far. Linux has been working on NTFS support since.. at least Win2k, which is a looong time. And now we have to worry about MS putting us back to square one.
I think it's a little sad that Linux has to waste so much time being compatible with MS software (.doc support, NTFS support, FAT support, samba). I'm not in any way saying we shouldn't be doing this, since everyone wants compatibility, but it's a real PITA we have to waste so much time playing catch-up with MS. Imagine where OpenOffice et al. would be today if they didn't have to worry about reverse engineering the miserable .doc format. We could wish that MS would play nice and ues open standards, but there's a snowball's chance in hell of that happening. They know exactly what they're doing, and how much it sets us back. Perhaps someday MS will be forced to play catch-up with us for a change. I guess you could say the IE team is doing that right now, but it's not like we're implementing non-standard features in our browser.
http://cltracker.net -- powerful craigslist multi-city search
Let's try reading a 32-bit value from the disk surface and masking out the top 3 bits (random file-systemesque example chosen off the top of my head).
Totally portable, totally trivial, and efficient --- any reasonable compiler will optimise out the 'return' line if it can.. (I'm assuming little-endian. May contain typos.)
This is basic programming skills. There is nothing the least bit hard here, and these days, people should be doing this kind of thing as a matter of course.
The latest knoppix CD uses an older version of this NTFS driver (read-only if I'm not mistaken) via FUSE and it is *slow*. Rsyncing an entire disk for backup purposes can take days (yes days). Disabling the fuse-ntfs system in knoppix and mounting using the read-only NTFS kernel-level driver is several orders of magnitude faster. So I think this driver is good for sharing data and doing emergency stuff, but it is no where near fast enough to think about using it as a root file system or anything. Knowing this latest driver is faster than Paragon's driver is good news; paragon's driver must have been even slower.
When the ntfs driver is stable, I hope it will be put in the kernel (at least as a native file system). Then we can consider adding a unix layer on it and install linux to the same drive as Windows, for those that want to dual-boot.
You could use this to boot from an ntfs partition if you wanted, just use a kernel based read-only driver to get to an initial ramdisk which includes enough support to remount the partition with this. Even without this you should be able to use a loopback filesystem on ntfs even with the older ntfs drivers as their write support is at least meant to be solid if you are not creating or changing the size of files.
Never underestimate the dark side of the Source
DOS natively supports fat32, but does not natively support NTFS - tha's what NTFS4DOS is for (google it). Incidentally, for Windows, NTFS is a far superior fs than FAT...
A filesystem really only has to work with a specific operating system and patch level.
What about external USB/Firewire hard drives? If NTFS file systems are no longer compatible between WinXP / WinVista and Win2000, there's going to be some gnashing of teeth by end-users who use those devices. Especially users who use those drives to move large amounts of data between multiple systems. (Segmenting a 300GB drive into 32GB partitions so they can be formatted by Windows with FAT32 isn't vary useful. Unless you get a 3rd party program to let you format larger partitions.)
Microsoft doesn't have a "portable" large drive filesystem other then NTFS that can easily be used on external drives larger then 32GB.
Making things harder for end-users is not in Microsoft's best interest, which is why there's unlikely to be any major changes to NTFS. (Not saying that MS won't shoot its customers in the foot, but it's improbable.) Doing so would drive (more) customers into the arms of Apple, Linux or Solaris.
Nonsense: NTFS is a Windows Filesystem. It's never had to be compatible with anything else, and they've clearly made no effort in letting it be. They have made changes in the past that have had consquences. (I'm not saying they made those changes to be evil, the point is, XP broke Nortons).
And who said they'd need to break XP NTFS to break Linux NTFS? I have no doubt at all the current version of NTFS is already prepared for whatever other layers of obfuscation they might add. Mark my words, NTFS was designed only to allow Windows to store and retrieve files, not you. Windows will be your vehicle for storing and retrieveing those files, they've worked damned hard at making it that way, and they'll continue to work damned hard.
printf("%s@yahoo.co.uk\n", uid[569754].name);
Random aside:
...) is often a complete flop, frequently requiring a quick followup release (W95OSR2, DOS 4.01) to rectify serious problems with it. At this point consumers start to lose cofidence and MS look for a new direction in order to convince people that their software isn't all that bad.
NTFS was actually launched in 1993, 13 years ago, when Windows NT 3.1 (really 1.0, but the version was matched to the MS-DOS-based Windows 3.1) was released.
It's interesting to note that this means XP (which identifies itself internally as NT 5.1) is actually NT release 3.1.
3.1 is typically the best version of any microsoft product (except DOS; 3.3 was generally regarded as better). Version 4 (e.g. Win95, DOS 4.00,
So, when Vista flops, what are MS going to replace it with?