Using the Real ntfs.sys Driver Under Linux 548
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."
OK... good (Score:2, Interesting)
I'm not sure if we'll see it in knoppix (Score:5, Interesting)
Knoppix (Score:5, Interesting)
I wonder how it's going to be done in Knoppix, without distributing a commercial DLL with the CD. Perhaps the following scheme could work:
Tricky. Depends on having the DLL somewhere on the disk.
-- Arik
How about the other way around (Score:3, Interesting)
What about users/permissions? (Score:5, Interesting)
"Secret" software is a real problem for OSS (Score:4, Interesting)
Useful (Score:5, Interesting)
How stable? (Score:5, Interesting)
Not 'free as in speech', but rather (Score:4, Interesting)
as a knoppix user, I hope to hell this stays WAY AWAY. Microsoft has published a good deal of api's for writing device drivers; it would be a better idea to develop OSS device drivers that allow read/write access to ext2/ext3/reiserfs filesystems instead.
Would be better legally, as well.
Knoppix won't have ntfs.sys ever (Score:1, Interesting)
Knoppix won't provide ntfs.sys because that is copyrighted by Microsoft. Now knoppix may allow loading the driver if you have nt/2000/xp on a hard-drive, but won't you need to load the linux ntfs driver first, if it's on an ntfs drive?
This may be a helpful idea for the short-term, but you're better off with more free-open-source-driver.
Re:I'm not sure if we'll see it in knoppix (Score:5, Interesting)
Use the copy off the hard drive. Mount it in read-only using the normal way, copy it to the Knoppix ramdrive, and then run the driver from there.
Re:OK... good (Score:4, Interesting)
-
Re:OK... good (Score:5, Interesting)
look at the windows boot loader (Score:2, Interesting)
so knoppix can probably find out where windows is installed by examining the bootloader for windows. i believe it points to the windows installation directory (which device, directory, etc.).
Call me crazy but... (Score:2, Interesting)
This would be very handy to me, since I use XP for Video / Photo Editing, Gaming, and Linux for everything else.
Am I crazy? Is this crazy talk? Why not give users the option to use Ext3, RiserFS, NTFS, etc all on the same page?
Re:I'm not sure if we'll see it in knoppix (Score:5, Interesting)
Um... I'm wondering here: How does Windows load ntfs.sys from an NTFS partition???
Re:What is this good for? (Score:3, Interesting)
Already in the works, chum. (Score:4, Interesting)
Re:I'm not sure if we'll see it in knoppix (Score:2, Interesting)
But the NTFS driver would be on the Windows partition, which would be an NTFS filesystem - right?
So presumably the setup looks like this:
Seems to me that either just "stealing" the ntfs.sys driver (wonder if it gets changed by different service packs?) or using the normal kernel one would be far easier.
But then again I don't use Windows so I have no NTFS partitions..
Re:Knoppix (Score:5, Interesting)
> 1. Look for NTFS partitions and mount them with the R/O driver
> 2. Scan those folders for the dll and copy it into the ramdisk
mount -t ntfs
if (-e
{
cp
}
umount
if (-e
{
# Do Wrapper voodoo here.
}
Doesn't seem to conceptually hard (or tricky) to me.
One reason (Score:1, Interesting)
Besides, Knoppix *already* includes NTFS support. It works just fine (A non-techie friend's computer became non-bootable. I used Knoppix to back up what he needed on system to CD, then replaced a few critical DLLs to get things to work again).
Re:MOD PARENT UP (Score:3, Interesting)
I would like to see ext3 for XP, and UFS too. Windows JFFS2 drivers for removable smartmedia would be nice too, but these things are a bitch to port. Ideally, you'll have a full debug (checked) build of XP and a second XP machine to run a kernel debugger on. One mistake in IFS code and it's off to bluescreen/reboot city.
Jon.
It ain't free if it requires ms-windows (Score:3, Interesting)
If the "Captive" (?) NTFS project needs the original MS driver it might also be illegal, and plain useless when there's no ms-windows around but only data to be rescued.
Anyways, if this project scratches someone's itches then who cares - go for it. At least one can always try pulling stuff like this under the open source skies. Try retrofitting ms-windows with non-ms-sanctioned FS support... now there's a challenge!
Re:What about users/permissions? (Score:3, Interesting)
Personally (Score:3, Interesting)
Re:How stable? (Score:2, Interesting)
Re:You better download this today. (Score:2, Interesting)
Microsoft may not, though. So, a person provides a tool to grant safe access to a resource--which you own--remember, that's your data on that drive. And Microsoft has spent quite a bit of money deliberately breaking existing compatabilities. Clearly this state--incompatability--has value to them.
It's not inconceivable that Microsoft might expend some effort to see that such a tool is not available for the public to use.
It's kinda like the whole "fair use" issue. Fair use says functionally what you posted--what you do in your house is your business. And interested parties cannot use legal means to directly curtail your rights to fair use.
What they can do, however, is make it technically difficult for you to exercise these rights.
So, sure, you can read your NTFS partition in your own house. And you can do it from another OS.
Too bad we bought off/intimidated/harassed/took out and shot the only author of the tool that allows you to do this. 'Course someone else might create such a tool, and they're free to do so. Care to try?
What about NT4 for non-x86 users? (Score:3, Interesting)
Would these drivers, assuming you have an NT4 disk gathering dust, be a solution for non x86 users?
Not much help if you run Linux on ARM or 68k or something but there you go.
Re:What about NT4 for non-x86 users? (Score:3, Interesting)
I don't think MIPS or PPC made it to NT4. Alpha died early in NT4 cycle, maybe a service pack or two. You're looking at very old technology. This still looks like x86 only.
Re:OK... good (Score:3, Interesting)
It is clearly always possible using simple methods (unless M$ do really stupid things with the disk format, and then it would break on some disks and/or controllers) to read what is on the disk, using Linux, or for that matter an old version of Norton Utilities (when there really were useful utilities). There is no shortage of people who could run simple file writes from Windoze, and read back the changes to see what had really happened. I could do that, given some basic instructions. So. gathering info is not too hard, making sense of huge volumes of it, all the special cases, error recovery and all that sort of thing, possibly working around deliberate obfuscation, may be another matter.
I wonder if it might be better to do a clean-room implementation of the .dll, one team, who absolutely never, ever writes kernel code, disassembles it (they may even do an instruction trace with an emulator if it helps) and writes a spec, while the other re-implements it, without having ever seen the disassembly. That is legal. The key is writing an accurate spec from the results of the disassembly.
I don't know which method the kernel team are using, but IMHO they need more help (people, not competence, which they already have plenty of), only it would have to be meaningful and properly coordinated otherwise it would be a nuisance. Due to the past history of damaged files etc, they really ought to have many thousands of beta, or even alpha, testers on this one, and not pass the code as fit for general use until many gigabytes on thousands of different PCs have been read and written successfully. If someone would publish a to-do list, they might well find that useful assistance would be forthcoming.
Re:OK... good (Score:3, Interesting)
Get people converted to an open filesystem, I say.
Re:First? (Score:1, Interesting)
All of these drivers I can download for free, but they are windows only.
What should I do? Buy better hardware that supports Open source? I can't afford it. I have el-cheapo crap hardware, with windows only drivers. Should I just use windows then?
What abou WinModems? Even they require some microsoft emulation to work. This is just one piece of hardware that is dependent on windows. By not supporting windows in linux, linux loses a lot of device support. Due to the nature of these device's dependence on windows, linux must emulate windows somewhere.
Windows driver emulation/loaders ARE a just cause for open source. Anything that gives linux better hardware support is good, IMO.
Anonymous FTP? (Score:2, Interesting)
Everything on my home network is heavily firewalled, so there is no danger of intrusion. Anonymous FTP lets me browse my Linux box with Internet Explorer. It very convenient and easy to use. I can create, delete, rename, and copy with no problem. I haven't tried it yet (I don't run a gui on my Linux box) but using Mozilla from Linux to anonymous FTP on Windows should work exactly the same.
Re:HPFS (Score:1, Interesting)
What about Mac Users? (Score:5, Interesting)
I'm not sure if you realize it, but there is no easy solution for using an external hard drive over 32gb with multiple platforms.
As of this driver, it appears that NTFS is probably the best way to do this, as it now has Linux support.
Windows or MacOS don't support Ext3 natively, and the 3rd party drivers are slow. Fat32 has a 32gb limit. Mac HFS+ can't be read by Windows.
How easy could it be to write an NTFS driver for OS X?
What about Other Windows Drivers (Score:2, Interesting)
Why? (Score:2, Interesting)
The current ntfs kernel module is able to understand the formating of ntfs in order to read it, but shouldn't that same understanding allow them to code proper "write" access as well?
It's obviously true that it's more difficult, but why?