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.
What's the last closed-source file system you completely reverse-engineered, then?
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.... ???
A fool throws a stone into a well and a thousand sages can not remove it.
Still years before NTFS will be documented. And Microsoft doesn't supply a ReiserFS or Ext3 driver even though those filesystems are documented.
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).
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.
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?
"Build a man a fire warm him for a day, set a man on fire and warm him for the rest of his life."
But Linux has ext[2|3], reiser[3|4], XFS, JFS, ... in its kernel, why can't Windows ?
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.
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.
"How to Do Nothing," kids activities, back in print!
Result? We were and are still playing catch up depending on who you speak to.
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.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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.
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.
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.
Duct tape is like the Force. It has a light side, a dark side, and it holds the universe together.
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.
http://outcampaign.org/
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.
Sometimes it's best to just let stupid people be stupid.
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.
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.
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.
#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.
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.
come on! The GP clearly said:
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.
Go read some of the work being done on microkernels, jeez just reading http://en.wikipedia.org/wiki/L4_microkernel_famil
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.
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.
I am TheRaven on Soylent News
I refer you to your original comment:
and then your supplied code:
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.