Forgot your password?
typodupeerror

Fully Open Source NTFS Support Under Linux 310

Posted by CowboyNeal
from the long-time-coming dept.
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 discussion has been archived. No new comments can be posted.

Fully Open Source NTFS Support Under Linux

Comments Filter:
  • Re:Yay (Score:2, Insightful)

    by Anonymous Coward on Saturday July 15, 2006 @10:47AM (#15724531)
    What's the last closed-source file system you completely reverse-engineered, then?
  • Re:Not Just Linux (Score:3, Insightful)

    by foniksonik (573572) on Saturday July 15, 2006 @11:05AM (#15724567) Homepage Journal
    Which means that this may make it into OS X 10.5 ;-p Hurray! Which potentially means that we Mac users 'could' run Windows dual boot AND use Parallels/VMWare with the same install of Windows AFAIK.... ???

  • Re:Yay (Score:2, Insightful)

    by Anonymous Coward on Saturday July 15, 2006 @11:11AM (#15724588)
    Still years before NTFS will be documented. And Microsoft doesn't supply a ReiserFS or Ext3 driver even though those filesystems are documented.
  • Re:Performance (Score:5, Insightful)

    by Ulrich Hobelmann (861309) on Saturday July 15, 2006 @11:16AM (#15724602) Journal
    Well, you can bet your ass that Windows's native NTFS is much faster than the Linux one, because they wrote the FS, and they have years of time to optimize the working driver.

    Sure, user-mode will be a performance issue, but I think the context-switch + work is only necessary, when the kernel decides to either read data (on a cache miss) or write out its file buffers to disk. So if you don't use NTFS as your native disk (not sure how that'll work with permissions and stuff), you should really by fine. Maybe there's an option somewhere to turn on big read-write chunks (so that the kernel will always read/write huge blocks from the user daemon, which would make context-switch time negligible).
  • Re:Performance (Score:3, Insightful)

    by jrcamp (150032) on Saturday July 15, 2006 @11:17AM (#15724610)
    Why would multiple users be using it at a time? The main use case for NTFS is recovery and people who need access to their files on dual boot laptops and desktops.
  • Re:Awesome! (Score:3, Insightful)

    by OmnipotentEntity (702752) on Saturday July 15, 2006 @11:22AM (#15724637) Homepage
    Linux *can* have ntfs support in the kernel. The developers just chose not to do it that way. FAT32 support is very stable. NTFS is still in flux as Microsoft is still developing it.

    From TFA, The driver currently is in BETA status: before release of this software we haven't experienced any driver crashes or data loss during our heavy quality testing, however we are aware of some minor issues which will be resolved in the near future.

    It's still in beta. While it's a GPL'd beta, and probably far more stable than beta implies. It's still beta, and you should expect it to bug out from time to time (whether or not this is actually the case.)

    So, if you have it when it bugs out as a kernel module you get a kernel panic. I don't like kernel panics, and you shouldn't like them either. So keeping it to the userland is probably best for now. Do you really need it as a kernel module?
  • Re:Awesome! (Score:3, Insightful)

    by lord_rob the only on (859100) <shiva3003@gmail.cBOYSENom minus berry> on Saturday July 15, 2006 @11:25AM (#15724649)
    But Linux has ext[2|3], reiser[3|4], XFS, JFS, ... in its kernel, why can't Windows ?
  • Re:Great news. (Score:5, Insightful)

    by cnettel (836611) on Saturday July 15, 2006 @11:27AM (#15724658)
    You can come with quite clever ways to hide data. The point is that the rootkit, to be an infection, must also have some way for a standard Windows routine to actually read that data and load it as code. In practice, it means that the real, non-rootkit-mangled, version of the registry will probably contain a reference, or that the normal data stream of some system binary will be changed as well.
  • by dpbsmith (263124) on Saturday July 15, 2006 @11:30AM (#15724663) Homepage
    This is the cue for Microsoft to roll out a new! improved! disk directory format.

    If I were Microsoft, I'd make just enough undocumented changes to screw up reverse-engineered implementations of NTFS... providing just enough increased functionality to which I could Point With Pride.

    I might even called it WinFS 2007 or WinFS X-Treme or Enterprise WinFS. It wouldn't have anything to do with the real WinFS... anything more than Javascript had to do with Java, or Mac OS 9 had to do with Copland, but it would certainly muddy the buzzword waters.

    Imagine a meeting with nerds and suits present in which the nerds make the mistake of mentioning Microsoft's failure to deliver WinFS, the suits would wave their magazine and say they had, then drum their fingers, yawn, and look at their watches while the poor nerds try to explain the complex technical issues and how WinFS was supposed to therblig the frammistan while WinFS Gold merely globulorns the ferthbernder.
  • by bogaboga (793279) on Saturday July 15, 2006 @11:47AM (#15724711)
    The `beef' is not whether Vista will use NTFS. The concern is that even if it uses NTFS, there will be an update to this NTFS that will "force" Linux into catch-up position. Guys, this develpoment is not in Microsoft's interest. Remember what happenning to Samba with CIFS/SMB? The underlying protocol remained basically intact but Microsoft kept updating the CIFS/SMB protocol.

    Result? We were and are still playing catch up depending on who you speak to.

  • by vtcodger (957785) on Saturday July 15, 2006 @11:55AM (#15724731)
    Full NTFS compatibility in Linux is a good thing. There are a gazillion scenarios where it is necessary for users to get at Windows files from Linux or vice versa without moving stuff over a network.

    But, keep in mind that NTFS remains proprietary and Microsoft can break it for newly written files any time it suits their business purposes to do so. All it takes is one update.

    No one but me seems to care about this, but I think that the proprietary and undocumented nature of NTFS is an important reason why System Administrators need to have a workable exit strategy for Windows. They don't need to exit now. But in three or five or ten years if (when) Microsoft decides to lock in its user base, users should want to make sure that they have the option of being outside the door that Microsoft is slamming shut.

  • Re:Performance (Score:2, Insightful)

    by iamacat (583406) on Saturday July 15, 2006 @12:21PM (#15724823)
    Actually, they should do no such thing. Kernel is big and complex enough as it is. Kernel drivers can not use virtual memory, explicit multithreading or advanced algorithms from MP, STL and hundreds of other C++ libraries. And when they have bugs, the system really crashes and burns as opposed to just a couple of processes getting file errors.
  • by Martin Blank (154261) on Saturday July 15, 2006 @12:26PM (#15724836) Journal
    But, keep in mind that NTFS remains proprietary and Microsoft can break it for newly written files any time it suits their business purposes to do so. All it takes is one update.

    Hypothetically, yes. However, there are few things that they -- or any OS developer -- are more paranoid about altering than the filesystem. You can recover from a bad driver, or a bad patch for most functions; recovering fully from a bad filesystem alteration may be nigh-on impossible, and Microsoft is going to think really, really hard before they go and do something that may result in lost data.
  • Re:Performance (Score:1, Insightful)

    by Anonymous Coward on Saturday July 15, 2006 @12:36PM (#15724861)
    The FAT filesystem is consistently faster on Linux than it is in DOS. I'd say against windows, Linux may still have the edge there, too.

    That's 20+ years of Microsoft support and Linux still beats it.

    Just because an FS is M$'s baby doesn't mean they know how to treat it right.
  • by mh101 (620659) on Saturday July 15, 2006 @12:45PM (#15724892)
    Um, since when is 'interoperability' the same as 'lack of innovation' and 'stealing'? Nobody's trying to 'steal' NTFS to use in Linux. Rather, people are looking for a way to access their data from Windows that's stored on an NTFS partition. I don't think any Linux users would willingly give up EXT3 or ReiserFS for NTFS.

  • by Schraegstrichpunkt (931443) on Saturday July 15, 2006 @12:52PM (#15724911) Homepage

    One nice thing is that Microsoft can't change things willy-nilly with NTFS as it could with, for example, the Word file format. The worst problem with NTFS write support is that a naive driver can cause data corruption. Once the free/open-source driver is sophisticated enough, there won't be much Microsoft will be able to do to exclude it, except by adding new optional features. There will come a point where anything that Microsoft does to break the free driver will also break older versions of its own drivers. Microsoft can't really afford to let that happen, since once thing businesses will not tolerate is a file system that arbitrarily loses data, especially since NTFS is currently viewed as being very stable in the Windows-using world.

    Breaking filesystems is much more drastic than breaking network protocols. The only thing that Microsoft could do that would effectively deter users of the free driver is to make it (and any older version of Microsoft's own NTFS drivers) cause data corruption. Even Microsoft isn't stupid enough to do that.

  • Re:Performance (Score:3, Insightful)

    by Reality Master 101 (179095) <RealityMaster101&gmail,com> on Saturday July 15, 2006 @01:07PM (#15724964) Homepage Journal

    It's a widely-believed myth, mainly due to the poor performance of bloated first-generation microkernels

    No, it's a widely-proven fact. Now, it may be possible to have a decent performing microkernel, but to dismiss performance problems as a "myth" is disengenious at best.

    some people are actually devoting much of their time to solving these problems.

    Exactly. "solving", implying that performance problems are hardly a solved issue. Now, I'm not here to knock microkernels -- they certainly have their place, and the advantages may end up outweighing the performance problems (as high level languages did with assembly language), but microkernel advocates really need to get over their oversensitivity on the issue. Screaming "myth" when everone's experience is to the contrary does your movement no good.

    Advocates ought to be saying, "Yes, microkernels are slower than monolithic kernels and probably always will be due to their nature, but with care the cost can be minimized, and we believe the clear benefits outweight the cost.

    That's at least a debatable statement.

  • Re:No 64-bit (Score:3, Insightful)

    by Tim Browse (9263) on Saturday July 15, 2006 @01:21PM (#15725000)

    surely any well-written code for a portable operating system, such as Linux, should be written in such a way that endianness and word size is irrelevant?

    I would have thought that fiddling with bitwise data structures on disk is pretty much one of the cases where endianness and word size is very relevant. I mean, I could be wrong.

    In fact, these days you'd pretty much have to go out of your way to ensure that it didn't work.

    Hmm. 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). Yep, I reckon you'd have to go out of your way to make sure that it did work across platforms with different word size or endianness. It's not exactly hard, but you'd certainly have to go out of your way.

    Especially as I'm guessing the number of times this driver has been run on a Linux PC that is not a 32-bit Intel x86 machine is currently close to zero, given the typical application of this software.

  • by peragrin (659227) on Saturday July 15, 2006 @01:23PM (#15725005)
    On one hand I agree with you. On the other MSFt is the same Company that brought us Fat32, Win Me, and Active X.

    Because every web developer in the world needs direct write access to any where they like on the hard drive, that doesn't have permission controls of any kind.
  • by Jairun (982778) on Saturday July 15, 2006 @01:23PM (#15725006)
    You are a moron.... I don't know any linux user who would willingly use NTFS. We are only looking to access files from the hated windows partition. Not to mention, sometimes it's easier to fix windoze when you are not acctually running it.
  • Re:Performance (Score:2, Insightful)

    by quintesse (654840) on Saturday July 15, 2006 @02:15PM (#15725164)
    #1 : To which the same AST says "The complexity is quite manageable. This is not speculation. We have already implemented the system, after all."

    He says that are basically only a few basic classes of drivers that you need this kind of complexity for, I imagine extending one for your particular filesystem, hardware, etc is a lot easier than having to write one from scratch each time.
  • Re:Great news. (Score:4, Insightful)

    by cryptoluddite (658517) on Saturday July 15, 2006 @02:27PM (#15725199)
    I had a disk with a problem of a couple bad blocks that cause NTFS to freak out. Connecting it to another Windows machine cause it to freak out also (as in ntfs driver hosed and left 2nd system's filesystem corrupt). So I wouldn't count on examining a Windows rootkit from another Windows system if I had linux available.
  • Re:Performance (Score:2, Insightful)

    by quintesse (654840) on Saturday July 15, 2006 @02:33PM (#15725222)
    but to dismiss performance problems as a "myth" is disengenious at best.


    come on! The GP clearly said:

    Performance problems are a well-known fundamental problem with microkernel architectures that use user-mode processes


    Look at the keyword "fundamental" here, THAT's the myth and the fact that several people, AST being one of them, have proven that there is no such "fundamental" difference is the "fact" here. Even coming up with a long list of examples where the performance is actually worse does not mean a thing, it might just mean it's very difficult or that no microkernel has ever gotten the same kind of attention as monolithic kernels.

    Yes, microkernels are slower than monolithic kernels and probably always will be due to their nature


    Go read some of the work being done on microkernels, jeez just reading http://en.wikipedia.org/wiki/L4_microkernel_family [wikipedia.org] will give you enough leads, there are _actual_ _working_ examples of microkernels that perform well, in some cases outperforming existing monolithic kernels.

    That's why people are screaming "myth" because people like you have already made up their mind and keep repeating the same old adage when it just isn't true.

  • Re:Great news. (Score:3, Insightful)

    by TheRaven64 (641858) on Saturday July 15, 2006 @02:39PM (#15725243) Journal
    You already have such a tool in Captive NTFS. True, that requires the Microsoft driver, but if you're going around fixing NT-based systems, you have that.

    You would, of course, have to have a copy on your recovery disk. The first thing I would expect a rootkit to do is patch the NTFS driver, so relying on the infected one would not be a good idea.

  • Re:No 64-bit (Score:3, Insightful)

    by Tim Browse (9263) on Saturday July 15, 2006 @05:20PM (#15725744)

    I refer you to your original comment:

    "In fact, these days you'd pretty much have to go out of your way to ensure that it didn't work."

    and then your supplied code:

    return buffer[0] | (buffer[1]<<8) | (buffer[2]<<16) | buffer[3]<<24);

    That code looks like it's going out of its way to deal with endian issues to me.

    As I said, it's not hard, but it's not free either. Perhaps we should just agree that your original comment was hyperbole and leave it at that.

  • by Martin Blank (154261) on Sunday July 16, 2006 @07:30AM (#15727533) Journal
    If they did release an update that trashed 1 or 2 % or Windows installs, they'd release another patch and the public would keep lapping it up.

    Take off the FUD hat and re-read what you wrote there. Do you really think that trashing 1%-2% of the install base would be smoothed over with a patch?

    Back in 2004, when SP2 was released, the estimated installation base for XP was more than 250 million systems. Throw in Windows 2000, plus growth since then, and I would think that a conservative estimate of 400 million 2000/XP/2003 systems wouldn't be out of line. The suggestion that four to eight million systems -- servers included -- could lose data and that Microsoft could just release a few new bytes to handle it is ludicrous at best. Microsoft would be hit with a class-action suit -- and deserve it -- for taking out so many systems.

    You can break drivers. You can break compatibility. You can even break mainboard hardware. In each case, people will move on. But when you break people's data, forgiveness is often impossible to find.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter

Working...