Using the Real ntfs.sys Driver Under Linux

caseih writes "A very neat hack uses the real ntfs.sys driver (obtained from your own windows XP partition and used via a wine-like layer (borrowed from ReactOS) to mount an ntfs partion with full read/write access. While not an ideal solution and certainly not free as in speech, this is an ideal stop-gap measure for many people trying out linux. I think that we'll probably see this in Knoppix pretty soon."

First?

[Anonymous Coward]

Project includes the first open source MS-Windows kernel API for Free operating systems

Surely that would be ReactOS, where he got a lot of the code from.

But still, so it begind. First NDIS drivers now FS drivers. Next up it will be a GDI wrapper for X so you can use Windows binary drivers with your graphics card.

All of this is a complete waste of time though. When did Open Source simply become a way to avoid paying for Windows?

Re:OK... good

[Anonymous Coward]

Well, it looks good to me for troubleshooting and forensic purposes. I wouldn't use this to mount an NTFS share housing mp3s however.

You hit it...

[lukewarmfusion]

right on the head. I'm still trying to make a real step into a Linux partition. I've been using Knoppix live and so far my bosses are mostly just confused. This might help me show them (and thus provide me a box to install on) how easy (and cheap!) this stuff really is.

Fsckin' Great...

[DeionXxX]

That's just great, I don't think there is a more annoying thing when dual-booting than not to be able to share files between the goddamn installations. Hopefully with this, each OS won't feel like it's on a different part of the goddamn universe.

BTW How did people get around this issue before Read/Write access to NTFS? Did they have a FAT32 partition or something that both of the OS installations shared? I never took too much time to look into it because it wasn't too much of a problem for me.

--D3X
NeoX3.com: Free of Clothes and Free of Charge [neox3.com]

I wonder...

[hookedup]

With the advent of 'WinFS', and now NTFS on linux..how long until we see a 'NixFS'

From what i've read about WinFS, a *nix 'version' would be quite nice.

To all the "can't go in Knoppix" posters

[BACbKA]

It would be perfectly legal for Knoppix to *know* that you might have an NTFS.SYS around on your computer, look around to see whether this is the case, and if it is, use your own copy NTFS.SYS.

Of course, Knoppix will never itself be packaged with the NTFS.SYS. But if you have an NTFS partition, you have a damn good chance of having an NT around as well, with the driver right in there.

I can only hope that MS doesn't insert some nastiness into the NTFS.SYS that would prevent it from running inside the framework described in TFA.

HTH

Re:What is this good for?

[jared_hanson]

That sort of thing is exactly what this is good for. Let's say you give a Linux distro to a friend so he can try it out. This could be a Live CD or a distro that will make your system dual boot.

In any case, your friend probably has a bunch of files on his Windows partition (likely NTFS formatted) that he wants to see if he can edit/view in Linux. If he can do what he wants, then switching to Linux becomes an option. So, with this, his NTFS partition is available and everything just works(TM). After all, your friend doesn't even know what NTFS is, but he does know when he can't get at his files.

In short, this makes transitions to Linux much smoother. People shouldn't have to keep a copy of a file on both partitions just so its available in both environmets. It becomes a pain to figure out which document is the most recent, etc. etc. And, BTW, I'm talking about the average user who doesn't have a network drive.

Re:I'm not sure if we'll see it in knoppix

[kasperd]

Surely it is illegal to copy the ntfs.sys driver and distribute it in another operating system

I was thinking exactly the same, but there might be a way around that. Knoppix just have to contain the wrapper code, the actual .sys file can be loaded from the harddisk (if present). Systems with an NTFS formatted harddisk and no ntfs.sys file are probably rare. Problems that need to be solved are, how to verify intergrity of the ntfs.sys file you are going to load (if you care about that), and how to actually load the ntfs.sys file from an NTFS filesystem. It is not entirely a chicken and egg situation, as Linux already have NTFS read support, which is far simpler than full read-write support. Besides loading ntfs.sys would even be a user mode task, and reading NTFS from user mode is probably easier to implement than doing it from kernel mode.

Re:Knoppix

[homer_ca]

Sure it could work. The kernel NTFS driver is reliable enough in read-only mode. If you have NTFS partitions on your computer, you most likely have an installation of Windows where you can copy that file. It just has to search all NTFS and FAT partitions for \WINNT or \WINDOWS. This won't work if you don't dual boot and have removable media formatted with NTFS.

Re:I'm not sure if we'll see it in knoppix

[gillbates]

The only people who would need it already have it as a part of their Win2k/XP/2003 OS. Why else would anyone be using NTFS if they weren't running Windows?

See this in Knoppix real soon...

[hackus]

while Microsoft says See you in court real soon.

That driver is a closed binary and is subject to the DMCA act as well as Federal and State copyright laws.

You put that binary on a CD guy and your asking for it, and besides, it isn't in keeping with GNU distro's recognition of existing copyright law.

GNU license fully recognizes copyright and IP laws in most countries, no matter how draconian they are. (i.e. specifically the US)

-Hack

Re:Linux File System?

[Ewan]

Linux doesn't rely on FAT32, never has. What it has is the ability to read and write from a fat32 partition if the users wants to.

Linux has support for dozens of other operating systems' filesystems such as FAT32 and NTFS from Windows, JFS from IBMs OS/2 and AIX, XFS from SGIs Irix, as well as several developed specifically for Linux - such as ext2, ext3, and reiserfs.

Of all the filesystems available for Linux, XFS is probably the most advanced of any mainstream operating system in the world, with far more in the way of features and reliability as NTFS.

Ewan

Re:Not 'free as in speech', but rather

[reidbold]

No.. free as in fair use. If someone has the particular driver on their system, then that person should be able to use it on the same computer under a different operating system no?

Writing ext/reiser drivers for windows would fulfil a different niche, (linux user switching to windows perhaps?). This is intended for windows users, who already have ntfs filesystems, switching to linux.

Re:I'm not sure if we'll see it in knoppix

[motte_fra]

well I do, and I'm pissed off. This kind of thing can happen when you migrate from xp, w2k, etc... to linux, with important data on an ntfs drive, and no sufficiently big spare disk to copy the data on a linux partition.

Re:NTFS, not good.

[Anonymous Coward]

Does it matter one single tiny little bit? Jeez, we're talking about transfering files between to enviroments. What could you ever possibly need to do between those two enviroments that wouldn't work if you used a FAT32 partition to transfer the data?

Re:What about users/permissions?

[Lehk228]

"emergency or migration purposes" Exactly That, the point is not that it will serve as a convenient way to store everyday files, it is good for fixing a messed up XP install or getting files you need under linux.

Re:Linux File System?

[ShavenYak]

Linux still runs on FAT32 itself, though the Open Source community continuously claims to be more innovative, etc..

Umm, no. Linux can read/write FAT32 filesystems, but typically it is installed on ext2 or ext3 filesystems. Or XFS, or Reiser, or JFS, or.... Basically, anything which supports Unix-like permissions. Does anyone still use the old Minix filesystem?

In theory I guess you could install it on FAT32, but it would be horribly insecure and very kludgey since FAT32 won't support permissions, symlinks, device nodes, sparse files, and probably some other necessities that I'm forgetting right now.

the tricky part

[twitter]

The tricky part is the usual M$ interoperability problem, Microsoft will break it. As soon as you figure out how to use it, M$ can pull a "system update" that changes everything right under you. They can even make it so that you harm your system or destroy information if you try to use it. They have done this for other sytems as far back as DRDOS [kickassgear.com]. It would not be hard for them to put in a flag that they know about, but you don't. It's Microsoft, they suck, use it at your own risk.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:What about users/permissions?

[Clover_Kicker]

>Ownership, permissions, sharing, all that stuff

That horse has been out of the barn for years. Once I have physical access to a computer, I can boot from an NTFSDOS floppy or CDROM and ignore all NTFS security.

This doesn't make things less secure. It may remind people that without physical security, there is no data security.

Re:The simple fact of the matter is...

[pyros]

dual-booters are pussies

That should be sending me a flag that this is just a troll or flamebait, but I'm biting anyway. I don't have the money to buy an extra machine so I can run Linux and my wife can run Windows. And I'm not such a zealot as to make her use Linux for tasks that she finds easier in Windows. There is no Photoshop for Linux, and the only legal ways to run Photoshop in Linux end up meaning I have to have a copy of Windows. (VMWare + Windows, Bochs + Windows, Wine + Windows DLLs). So if I'm already paying for Windows, then I may as well dualboot it and avoid the performance hit of VMWare/Bochs/Wine.

Re:What about users/permissions?

[Anonymous Coward]

You can also install a second copy of Windows and bypass all the ACL security. It's not intended to stop physical access -- use encryption instead.

Re:How about the other way around

[ivan256]

I would *strongly* recommend doing a backup before trying any of the code from the ext2fsd project on sourceforge.

bah. i hate these. non-x86 users suffer.

[Splork]

those of us on non-x86 platforms that want read/write NTFS access to external (firewire / usb2.0) drives will only suffer due to driver emulation layers like this.

it satisfys much of the normal x86 crowd which means development of the real driver suffers.

Re:OK... good

[lysander]

OK, so therefore, Windows 95, 98, ME, 2K and XP are ... all Win32 emulators.

They are all win32 implementations with a common API. It would be a stretch to call them emulators, IMHO.

Re:OK... good

[tiger99]

Is that safe enough, or complete enough? Having had an NTFS partition badly damaged by Linux soem time ago, I don't really want to try it yet.

I do appreciate the difficulties the kernel team have had with this, it is not their fault that they have to work with an undocumented closed-source file system.

The strange thing about all this is that very many different OSs which have existed over the years have had some capability to read and write "foreign" file systems, either built in or as a third-party driver. Certainly it is standard with Linux, *BSD, even the hated SCO, also MAC in most of its variants, Amiga, Atari, Solaris....... Even many 8-bit computers could read a variety of foreign file systems. The one name missing is M$, absolutely none of their stuff recognises any othe OS at all. (Please correct me if I am wrong!) It is as if Bill arrogantly imagines that there are only Windoze PCs in this universe. The fact is that there are many things that can't be done under Windoze, but are relatively easy under some other OS. Maybe the reverse is true also, but I can't think of an example. It is absolutely normal in this day and age, even without open source, to need to read and write foreign file systems. The one obstacle is the Chief Hacker of Redmond, he will neither interface to other people's file systems (despite having the documentation, and most drivers under BSD licence) nor will he let anyone else do it by denying proper access to his documentation.

One day, when the masses wake up to what they have been denied since Messy-DOS 1, he may realise that his monopolistic actions have in fact shot himself in both feet.

Re:OK... good

[shaitand]

Before even bothering to ask if you COULD do it, better decide if you SHOULD do it. Would you really want a windows dll destablizing the kernel? The minute you let windows code into the kernel we are little better off than windows users in terms of stability.

Re:OK... good

[PetiePooo]

There are existing OSS NTFS drivers that work in read-only mode right? Well, here's a way around the MS EULA for most: make loading ntfs.sys a three-step process:

Mount the NFTS partition you want write access to using the OSS read-only version,

read the winnt/system32/ntfs.sys driver into memory or RAM-disk,

remount it using the method described in the article.

This way, Knoppix (or whichever distro implements this) wouldn't have to include the EULA-protected M$ driver. Its as legal as any other WINE-like use of existing, O/S-speicific DLLs and drivers.

Obviously, this wouldn't work for NTFS partitions that don't have an actual NT-based O/S installed on it, but if that's the case, why do you have that partition on your HD in the first place?!

Re:OK... good

[shaitand]

wine is a win32 implementation with an incomplete but common api. It would be a stretch to call it an emulator IMHO.

Re:OK... good

[teklob]

Maybe the reverse is true also, but I can't think of an example.
games

The translator *is* the emulation

[adiposity]

The extra layer, wherein an executable's calls are "translated" into *nix calls, is most certainly emulation. It allows an executable to run as if it were in one environment, even though it is not.

All an emulator is, is a translator. It's simply a question of how much is translated. If you want to say, "WINE is a really efficient emulator, because it doesn't have to translate every single assembly instruction," you'd be right. But it is STILL an emulator, because it still emulates having the win32 api.

Do win32 executables run on *nix systems? No, *nix systems don't know how to interpret them. By virtue of the WINE emulator, however, the part that *nix doesn't know how to run is translated into something that it does know how to run, while the part that is consistent between win32 and *nix can simply be passed through.

If WINE were not an emulator, you wouldn't have to run the win32 exes in WINE, you could just run them in the shell.

All that said, does the fact that WINE is really an emulator make it bad? No, of course not, especially since it is an extremely efficient one. Of course it's not a pure hardware emulator, so many ideas of inefficiency associated with emulators don't apply. But when you get right down to it, it's allowing binaries designed for one system to run on another, and even if it's more efficient than running on the original platform, that still makes it an emulator.

-Dan

Re:I'm not sure if we'll see it in knoppix

[RoLi]

Surely it is illegal to copy the ntfs.sys driver and distribute it in another operating system, seeing as how it is a part of Windows.

If you need NTFS-support you already have it on your harddrive, so no problems taking it right off the disk.

Re:Not really

[Politburo]

Linux supporters will never acknowledge the skill of Windows programmers except on one issue: The ability to magically alter code so that it not only breaks everything Linux related, but corrupts your data. Somehow, this code keeps running perfectly on every existing Windows installation.

Then again, that kind of trick is always described as 'easy' as well, so I guess credit isn't being given. Though if it were so easy, you'd think Microsoft might be doing a bit more of it, no?

Re:OK... good

[Phillup]

Chances are that if you need to read/write NTFS drives... you have an OS that put the data on the drives.

More times than not...

Now, why might I need this?

Suppose I'm doing a project in Delphi and Kylix... I may want to scoot over to my NTFS drive to pick up some code I wrote last night to put into the Kylix version... and I don't want to reboot to do it.

I'm still SOL going the other way tho... (of course I have a server that I back both systems up to, and that is how I've "solved" the problem... this reduces the hardware need a bit)

Re:OK... good

[drsmithy]

It is absolutely normal in this day and age, even without open source, to need to read and write foreign file systems.

Ah, while there are certainly quite a few people out there who want to read and write multiple filesystems, I'd hardly call it "normal". "Normal" is something my grandma or a secretary does with their computer.

Re:OK... good

[demon]

It's not an emulator by any accepted definition by anyone who knows about computer science. It's a binary loader with a Win32 ABI. It doesn't have to emulate anything on an x86 system. Now if I run Wine on my PowerBook to run a Win32 binary, _then_ I'm emulating. (Emulating an x86, that is!)