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.

Comments

Great news.

[LinuxGeek]

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.

Re:Great news.

[maxume]

Are the root kits so insidious that it is dangerous to put them in a throw away windows box as a non boot disk? That would seem like a fairly effective way to study them. I don't think I would want to go through that as a repair procedure, but for research, a disk swap seems easy enough.

Re:Great news.

[Tim C]

You also can't hide from a different installation of Windows that has the infected disk mounted. Rootkits hide themselves by hooking into the running kernel/fs drivers - inspect the disk with a clean install and they can't hide then either.

Of course, the more tools you have available to you, the better, and while it's very unlikely that a rootkit from one install can infect another as long as you're careful, it's *extremely* unlikely that it'll be able to infect a Linux install. That may change with time, of course - as with so many things, it's an arms race, and this one is unlikely to do anything but get hotter.

Re:Great news.

[Vo0k]

AFAIK most of their methods of protection would fail. Still, they could quite nicely hide in "alternate data streams" - every file or directory in NTFS chan have arbitrary metadata attached to it. Usually it's things like ownerships, permissions etc, but 'arbitrary' in this case means that besides the official metadata you can attach whole files making them invisible in the filesystem tree, existing in separate namespace, each file entry being a root directory for a whole invisible filesystem. So plain 'ls' won't show them. You need a tool that will examine each file, extract its metadata, discard the "standard" metadata and list whatever has been attached to files additionally.

Re:Great news.

[Anonymous Coward]

Can't hide from a Linux boot disk and with complete write support, now these can be cleaned and studied more effectively.

They can't hide from a Windows boot CD either, and given that NTFS is a proprietary file system (i.e. open source drivers will always be playing catch-up), I'd be more inclined to trust the official NTFS drivers on a Windows boot CD.

The Windows Vista (beta) setup disc boots to a live system, which can be used for repairs and whatnot, but with older systems like XP, it's a bit of a hassle, in that you have to build your own CD (there are tools available for download that make this easy for the technically inclined, but for novices it's still difficult). In any case, anyone with the competence to use a Linux disc to repair Windows should have no problem building a live Windows XP (or 2003) disc, and using it for repairs.

What this driver is good for is accessing data on a Windows partition from Linux. I primarily use Windows, so I like to keep my data on NTFS partitions, since all the Windows security attributes are meaningful. Although drivers for common Linux/BSD file systems are available for Windows, in my experience, the security attributes can only really be meaningful in one OS or the other, so I'd prefer to keep them meaningful in the one I use most, i.e. Windows. Being able to read and write from Linux, however, is a nice feature to have, especially with good performance, and either a reliable KM driver or a UM driver that's at least reliable enough not to corrupt the file system.

Re:Great news.

[cnettel]

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.

Re:Great news.

[Anonymous Coward]

there are tools available for download that make this easy for the technically inclined, but for novices it's still difficult

Exactly. This is how most tech people make money, they know more than the average "Click OK no matter what it says" windows users.

It's this dumbing down of windows that lowers the entry level for computer users. Now we have a zombie mob if retards that don't know how to take care of thier computer.

Re:Great news.

[GuidoW]

Of course, the more tools you have available to you, the better, and while it's very unlikely that a rootkit from one install can infect another as long as you're careful, it's *extremely* unlikely that it'll be able to infect a Linux install. That may change with time, of course - as with so many things, it's an arms race, and this one is unlikely to do anything but get hotter.

Potential solution:

• Install linux on a different physical harddisk and unplug it whenever you use Windows. Maybe put the least used one on an external hd.
• Use a bootable linux-cd, like Knoppix for daily work.

Okay, both of these are very unpractical...

Re:Great news.

[EXMSFT]

Vista setup uses WinPE - which is available now for many Windows business customers as well.

Re:Great news.

[Vo0k]

or that a vulnerablity of some metadata-reading program will be exploited. Say, buffer overflow in reading the metadata of "infected" file. Even in non-privledged program this will allow the rootkit to execute and escape the alternate data streams sandbox, then proceed with escalating its privledges and doing all the nasty stuff. This means there will be only legit entries in the registry and original (even though vulnerable) binaries in the normal data namespace.

Re:Great news.

[Anonymous Coward]

It's this dumbing down of windows that lowers the entry level for computer users. Now we have a zombie mob if retards that don't know how to take care of thier computer.

It's a bit like driving cars on public roads, really. Before the Internet, using a computer was like driving a car on your own land: no matter how badly you drive, you're unlikely to harm the public at large (apart from externalities like pollution). The Internet, on the other hand, is like public roads, and the results of unqualified users connecting their PCs to the Internet are more or less the virtual equivalent of the sort of thing we'd get if there were no regulation of cars/drivers.

I'm not sure that I like the idea of state regulation of access to the Internet, with licensing of computers and Internet access (along the lines of licensing of cars and driving licences), testing to ensure competence and regulation of traffic across national borders, but it might be the only way to promote responsible computer use.

For those of us who are technically minded, the current situation isn't so bad, since we know how to avoid all of the malware circulating through the Internet, irrespective of which operating system we're using. I don't mind the current situation at all (in some ways, I even enjoy it), but with all the havoc wrought on the non-technical by their own lack of computing skills, maybe regulation would be better for the population as a whole.

Re:Great news.

[Animats]

Yes. I expect that the next generation of virus-removal tools will be bootable Linux CDs. The "rootkit" attacks are becoming so intrusive that fixing them from inside the running system is becoming hopeless. It has to be done from a stable environment that can't be corrupted, like a read-only CD.

Re:Great news.

[MPHellwig]

Virtualization is both a problem and a cure for the same and different things and practical enough to be usefull

Re:Great news.

[Schraegstrichpunkt]

You also can't hide from a different installation of Windows that has the infected disk mounted.

In theory (assuming a sufficiently naive theory) that is true. In practice, all it takes is Explorer and something like a few WMF files. Heck, Explorer renders HTML for its thumbnail view, so it probably wouldn't be too hard for an attacker to find an exploitable bug somewhere in that code path.

Re:Great news.

[fm6]

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.

I can see advantages to an open-source NTFS driver: usable from a non-Intel Linux/Unix box, or in an enterprise environment where you don't want to buy a Windows license for every system that needs to access an NTFS disk. (Though you can always cheat, and hope you don't get audited by the IP police, as many companies do.) But it's not exactly an earthshaking development.

Re:Great news.

[FLEB]

I'm not sure that I like the idea of state regulation of access to the Internet, with licensing of computers and Internet access (along the lines of licensing of cars and driving licences), testing to ensure competence and regulation of traffic across national borders, but it might be the only way to promote responsible computer use.

It doesn't need to be government. The "abuse@" system for ISP (usually? sometimes?) fulfills that role.

Re:Great news.

[Bert64]

Usually not.
Large consumer oriented ISPs (ie: the biggest ones) have far too many customers, and far too few staff monitoring abuse@ (if any), and far too much red tape to cut through to get anything done anyway.

Re:Great news.

[Thing 1]

You also can't hide from a different installation of Windows that has the infected disk mounted. Rootkits hide themselves by hooking into the running kernel/fs drivers - inspect the disk with a clean install and they can't hide then either.

Interesting approach: install VMware Server (free), install Windows into a VM (free if you have 2003--IIRC*, Microsoft allows 4 instances, 1 host and 3 virtual), then connect the physical drive to the VM. Not sure whether VMware will bypass the drivers and allow you complete physical access as I haven't tried it but that's one of the options when creating a new virtual hard drive.

You probably don't want to run the VM from the same drive that you attach to it, though... I haven't tested this, but it might be a nice option for investigating without taking down any services that may happen to be running on the potentially-infected PC.

* -- is this the sound made by a crashing car?

Re:Great news.

[cryptoluddite]

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:Great news.

[TheRaven64]

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:Great news.

[Anonymous Coward]

But only the state has the power to really enforce it. Imagine if roads had been built by numerous private firms, with each one regulating traffic on its own roads (whilst trying to keep running costs as low as possible, without the power to arrest/fine violators, etc.), and no laws requiring car registration (hence no number plates) or driving licences. There would be chaos on the roads, just as there's chaos on the Internet today.

Re:Great news.

[Anonymous Coward]

hmm. i wonder who will be the first to make a virtualization of a small linux/windows OS that runs inside the current os and does the rootkit scan from there?

Re:Great news.

[Rich0]

You also can't hide from a different installation of Windows that has the infected disk mounted. Rootkits hide themselves by hooking into the running kernel/fs drivers - inspect the disk with a clean install and they can't hide then either.

Completely true, but it is a lot more convenient to scan with a linux boot-CD than to keep two windows partitions on the same computer and take turns scanning one from the other. I don't believe there are any windows boot-CD solutions, and I believe that the reason is licensing (and of course lack of interest on the part of MS).

If this driver matures you can bet that it will become the technique of choice for supporting NTFS on a boot disk - you'll see companies like AV and disk imaging vendors jumping on it.

Re:Great news.

[Cobralisk]

I remember running across BartPE. Its a windows live-cd option. I don't particularly care for it, but it has its place.

Re:Great news.

[cnettel]

Good point, but this, to a degree, still counteracts the argument that it can be very well hidden. If it is an abnormal copy of one of the more normal data streams, it will conversely get at least a bit easier to find. On the other hand, a malformed stream with a "summary" string for a file might seem more innocent than the single odd file with a stream name that's not found anywhere else.

Re:Great news.

[fm6]

Good point.

Re:Great news.

[Vo0k]

Remember that hiding in alternate data streams is a "last resort" tool. These are normally not scanned, and I'm really not sure about their support under other OSes, so this allows for some obscuring of them, but still the primary method of hiding the rootkit is to remove all visible vectors of access to it from the running OS - actively override directory listing etc in the filesystem drivers or stuff like that - as long as you're running OS from the infected filesystem you will -not- see the rootkit. The only access would be through an OS from alternate boot - preventing the rootkit from even starting its cloaking devices, when "alternate data streams" could provide some hideout - but generally when it comes to this, you're so bound on finding the rootkit that they will not help. In basic case there's simply no way to guess they are there, so why scan, why seek when you see no hint there is any need to... ...and if they are overflow exploits on a common general-purpose program (windows explorer?) if you insert the disk in a different windows machine and access it... ouch, you just infected the other machine :)

Re:Great news.

[Jeremy Allison - Sam]

No, you can execute directly out of the alternate data stream so long as you end the stream name in .exe....

See here:

http://www.infosecwriters.com/texts.php?op=display &id=53

for details. It shows a process listing with myfile.txt listed as a running process.

Scary stuff :-).

Jeremy.

Re:Great news.

[Doctor Memory]

if you have 2003--IIRC*
* -- is this the sound made by a crashing car?

Yes it is, IIRC.

Re:Great news.

[Cromac]

Take a look at Reatogo, it's much closer to a Linux live CD than the basic Bart PE is. Not quite as full featured as Knoppix, but quite good.

Re:Great news.

[Anonymous Coward]

Of course you could always just use a Windows PE disk.

Re:Great news.

[eneville]

> Vista setup uses WinPE - which is available now for
> many Windows business customers as well.

WinPE? That sounds like a fast food chain in the UK, wimpy, http://www.wimpyburgers.co.uk./

Re:Great news.

[angulion]

Didn't know about this in practice and found it an interesting read - Thanks for the link.

What I find a bit scary is that for example AVG Free Edition (Antivirus) did scream about eicar.exe (test virus), but it does not seem to see mytestfile.txt:eicar.exe

Re:Great news.

[the_B0fh]

Dude. Microsoft will not do such a silly thing as allow you free use of windows. Unless it's trying to kill a competitor, in which case, its free. If you are using the Microsoft virtual server. NOT Vmware.

Re:Great news.

[Anonymous Coward]

You two are funny

Re:Great news.

[Anonymous Coward]

Especially great. Am mailing this from a win98 install kept for utility purposes.
Son drops by here ever so often to get away from his girlfriend and mail to all his
internet nekkid cuties. Well one of his favorite sites gave him digital clap. ...I meant gave US digital clap. The full ovation! It was the 'cowabanga' worm.
To make a long story short, windows could NOT clean itself. It took Linux to do that!
Linux in the form of SuSE 9.0! SuSE 9.0 is the last linux in the SuSE line to be able
to do a virus cleaning. Seems the microsoft people must have agents in Novell 'cause
they deleted the shred function from their distros. Any linux distro with the 2.6 or
newer kernel does not have the shred function. It aint there. Try to find a shredder
for linux! Anywhere!!!!??! All you will find is some lying propaganda put out by
some sock puppet from microsoft or some similar bought and paid for liar for them
or from some government. The propaganda lie goes on about not being able to really
erase 'digital media'.......so that is why you are now not allowed to have the ability
at all!!!??? So anytime you go looking for a shredder program and get presented by
google with a list of sites all directing you to a 'study' about 'futility' of 'erasing
digital media', you know you are being sent to the mouthpiece of the monopoly or one
of his close lackeys. The lie is supposed to sell you expensive 'encryption' programs
that governments and monopolists all have the key for. It is also craftedto lull you
into a false sense of security. God knows what for, but God also knows this sure ain't
paranoia. Thats only for when there are no monsters under the bed. Due to the new
kernels coming out, it is only a matter of time before windows virii will work on linux
as well. Ximian is the foot in the door for this. This not so little and quite proprietary
mail and 'contact management' program forces you to accept HTML and javascript and java
in your e-mail. And it forces you to open it in its full 'viagra ad glory' in order to see
what it is. I also notice the new distros like to hide the hexedit program, and not install
it by default as well. Next they will drop it altogether. I will leave further judgements
up to you. I have presented only the facts which can be checked by anyone with a smallest
skill at looking in the internet and all its search engines. There is a remnemt of a 'wipe'
program, but it is a console command line text interface program completely, and is cumbersome
to use. If you have to dispose of a large number of malware files, you will have a lot of
work. I DO mean a lot of work. SuSE 9.0 slaughtered over 2 thousand files of adware, gambleware
and other malware in less than ten minutes. With 'wipe', you will be some days doing that.
All depends how much time you want to waste. But if 'wipe' is all you have and you cannot get
a better tool like Konqueror under KDE 3.0 and kernel 2.4, then it is necessary work that you will
have to do.

Re:Great news.

[Thing 1]

Dude. Microsoft will not do such a silly thing as allow you free use of windows. Unless it's trying to kill a competitor, in which case, its free. If you are using the Microsoft virtual server. NOT Vmware.

Hate to break it to you, but you're wrong.

The text from the linked article, for those too lazy (emphasis mine):

The Next Round in the Virtualization Wars
Posted by samzenpus on 2006-07-13 0:23
from the in-this-corner dept.
GvG writes

"After making Virtual Server available for free some time ago, Microsoft announced today it is offering Virtual PC as a free (as in beer) download. They also announced a change to the Vista license related to virtualization: Customers who deploy Windows Vista Enterprise have the ability to install up to four (4) copies of the operating system in a virtual machine for a single user on a single device. Even better, nothing in the license requires that Microsoft Virtualization technologies be used - if you want to use a competing product as your Virtualization solution, you still get the four extra licenses for use with VMs."

Re:Great news.

[darkonc]

* Use a bootable linux-cd, like Knoppix for daily work.
Okay, both of these are very unpractical...

I've been there.. I've installed a knoppix CD image on an external drive in a USB enclosure. I can then use a (modified) Knoppix CD that uses 'fromhd=/dev/sda5', to finish the boot from USB.

I've also installed a CD image on my main box, and setup GRUB to boot from it. I can then mount /home/knoppix from another partition (in KNOPPIX/knoppix.sh) (or even the same partition if I remount the CD image partition R/W and load any extra packages from either the CD (safest) or the HD partion (more convenient). I've used that kind of setup for my basic desktop CD for most of this year (Just switched to a real ubuntu setup this month for various technical reasons).

Updates are a breeze -- I copy the latest Knoppix CD to another partition, copy in the extra DEB files and setup a GRUB stanza. One nice thing about it, from a security standpoint, is that the compressed disk image is relatively hard to compromise (and easy enough to check from the CD miniroot if I want to be paranoid).

As a proof-of-concept, it's been pretty effective. If I move the setup to an external USB HD, and combine it with a (credit-card sized) knoppix boot CD, then I've got a fully portable knoppix desktop. If I put it on a 2" laptop drive, then I can fit the whole thing in my shirt pocket. (( I'm currently using a full-sized USB enclosure)).

Nothing for you to see here. Please move along.

[roger6106]

Nothing for you to see here. Please move along.

Is Slashdot testing out the NTFS writing ability on their site?

Performance

[Reality Master 101]

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.

Re:Performance

[Ulrich Hobelmann]

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

[jrcamp]

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:Performance

[Anonymous Coward]

Yup, just like Windows' own shared folders are faster than Samba.

No wait...

Re:Performance

[Anonymous Coward]

Any sources or references for that? ISTM that single-vs-multi-user would have make no difference whatsoever to a user-mode driver -- since by the time the driver does something you already went from the application to the kernel to the user-mode-driver, the driver has no way of knowing where the request even came from - so how can it be different?
I think this is especially true for a disk driver, where waiting for a platter to spin and an arm to seek are pretty much the only things that make them fast or slow since the CPU's so fast compared to the moving parts.

Re:Performance

[Reality Master 101]

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.

I agree that this probably won't get heavy use, but the developers shouldn't scream about how fast it is if that's not truly a consideration (and it's not truly a consideration if they're running it in user mode).

Re:Performance

[Reality Master 101]

Any sources or references for that?

Performance problems are a well-known fundamental problem with microkernel architectures that use user-mode processes. If you're interested in the subject, there are lots (and lots) of discussions about it (hint: your instincts above are wrong). Google is your friend.

Re:Performance

[zataang]

I fail to understand your logic. Why would you have multiple people accessing a Windows partition? Either you have a Windows server, or you have a Linux server. I just don't foresee having an NTFS partition on a Linux server (which serves multiple users) being so actively used as to cause performance problems. Also, being in the user space has its own advantages in terms of robustness. Given that ntfs is not documented (well?), I would be much more assured if the module stays out of the kernel. Why do I need to suffer random crashes?

Re:Performance

[kevin_conaway]

Why would users even need more than 640k of ram?

Re:Performance

[iamacat]

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.

Re:Performance

[Anonymous Coward]

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.

Re:Performance

[Schraegstrichpunkt]

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

It's a widely-believed myth, mainly due to the poor performance of bloated first-generation microkernels like Mach, although I suppose it probably also applies to Linux when Linux acts as a microkernel.

Google is your friend.

Just because Linus Torvalds thought something was impossible during the 1990s doesn't make it so, so I suggest you skip the infamous Linus vs. AST discussion from that time period.

The reality is that:

1. Microkernel architectures are hard to design. This is suspected as being the real reason why they are not very popular today.
2. Monolithic kernel architectures are prone to insecurities. There is just way too much privileged code, and too many failure scenarios.

Unlike Linus, some people are actually devoting much of their time to solving these problems. AST is one such person. See this page on the subject.

Re:Performance

[ArbitraryConstant]

While an NTFS kernel module with awesome performance would be nice, we haven't even had reliable writing before this (not without the Windows NTFS driver). It wasn't just a lack of performance, it was so bad that you'd need to do stuff like keep an FAT32 partition for transferring files. You won't run your high-traffic website on this, but it is still extremely helpful.

For the purposes of making a dual-boot system less painful, it's great. Now all we need is a Windows driver for Reiser...

Re:Performance

[Reality Master 101]

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:Performance

[budgenator]

It's been a while but it seemeed to me that not only did linux read/write windows filesystems both on the same system and over the network faster than windows did, but that the reverse was also true!

Re:Performance

[azhrei_fje]

Kernel drivers can not use virtual memory, explicit multithreading or advanced algorithms from MP, STL and hundreds of other C++ libraries.

Wow, I don't know where to start with this. First, mod parent down using -1, vague.

Have you written a filesystem? I have. The "virtual memory" you're apparently referring to is the process' virtual memory. This sounds like what you're trying to say is that the protection provided by process virtual memory isn't available in the kernel. And that's true. But that doesn't change the fact that the kernel can map any physical memory to any effective address. So the statement that the "kernel can not use virtual memory," is extremely bogus. ("Bogus" is a technical term. It means "completely wrong.")

Concerning "explicit multithreading," you must be referring to the idea that the kernel can't call pthread_create()? But there's no reason for the kernel to do so. Multi-threading in a user-level process is often done to achieve concurrency related to the delays that a single-threaded application would have if it had to wait for I/O to complete. The kernel doesn't have to do that at all. The kernel would queue up the I/O request, then continue on its merry way. When the interrupt from the device signals that the I/O has completed, a separate handler takes care of it. In a user process, threads are useful in order to modularize the I/O functions. In the kernel, they often aren't needed, since callbacks are used instead. Same functionality, different design technique. And even if they are needed for some obscure reason, all modern kernels (Linux included) support kernel threads. (My SUSE Linux 10 box currently has 19 kernel threads executing.)

The "advanced algorithms" you're referring to are probably coming out of user-space libraries. And in this regard, you're correct -- user-space libraries cannot (currently) be linked into the kernel and there is plenty of debate about whether such abilities should even be attempted. (The problem with user-space libraries inside kernel space revolves mostly around bugs and implementation deficiencies. The truth is that an algorithm that is mostly cpu-intensive probably could be loaded into kernel space using some kind of hack, and there are open source projects that are already working along these lines.)

In any case, there's no reason why those algorithms couldn't be executed inside the kernel. For example, take the find() generic algorithm from the STL (a macro from one of the libraries you mentioned). Why can't I use it? (The truth is I can.) And why can't I use the list class from the same library? I admit that linking large objects into the kernel could result in quite a bit of bloat, but there is not a technical reason that it couldn't be done. (Except in the case of C++ exceptions within the kernel. There is a group that has patches available for the Linux kernel that add support for C++ exception handling. With those patches, any STL code should be able to work in kernel space, although I've not tried it personally.)

It seems to me like the parent has read a magazine article and jumped to conclusions. Or perhaps they are even an experienced developer, but took huge liberties with the wording of their statement. But as "Captain Obvious," I felt it was my slashdot civic duty to clarify he issue. :)

Re:Performance

[quintesse]

#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:Performance

[timeOday]

Actually, they should do no such thing. Kernel is big and complex enough as it is.

As long as all the code for a given filesystem driver goes into the kernel module specific to that filesystem, I don't see the size/complexity issue. It's the same total amount of code, give or take a few lines, whether it ends up executing inside or outside the kernel. It's not like some new kernel feature that cuts across all aspects of the kernel.

Re:Performance

[quintesse]

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 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:Performance

[cryptoluddite]

It seems to me like the parent has read a magazine article and jumped to conclusions. Or perhaps they are even an experienced developer, but took huge liberties with the wording of their statement.

No what he said was perfectly reasonable, you are just being overly literaly. Yes there is memory allocation in the linux kernel, but it's not swappable. Yes, you can put an extra 1 megabyte of standard C++ library in the kernel to support your filesystem and make it fast, but then you have 1 megabyte less for caches and program data, not to mention the space wasted by these to favor performance. Check out the 'standard library' of functions that come standard with the linux kernel. Other than a few crypto it's limited to 'strlen' and friends.

A user-space filesystem, especially one a fantastically complex as NTFS, can be very much faster in user-space. For example, the user-space one can easily render the filesystem structures into something speed efficient but not space efficient. When you go to use the fs these get swapped back in as needed, so you may get a slow latency on the first request but then subsequent ones fly. Another huge factor is being able to focus on the actual optimization rather than managing memory and coding in a demand-driven style like in the kernel. For example, being able to issue one read command for 1 gigabyte of sequential data on the disk is far more efficient than 256 thousand 4k ones.

I've also done kernel coding and yes if you have unlimited resources a linux kernel driver will be faster than a user-space one. But when you don't even have resources to port to 64-bit you're going to be lucky just getting read support in your kernel driver whereas the user-space one will be doing writes already.

Re:Performance

[Reality Master 101]

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.

AST himself said at the site the poster above linked to, "In this paper we argue that for most computer users, reliability is more important than performance and discuss four current research projects striving to improve operating system reliability."

If performance is exactly the same or better than monolithic kernels, as you claim, why would AST make an issue that reliability is more important than it, unless performance WAS an issue? Why wouldn't he write a paper titled, "Having your cake and eating it too... better performance AND better reliability. Why microkernels have won the war."

The answer is because they AREN'T and NEVER will be for general purposes. Sure, you can find isolated tests or isolated projects where they might do better (and the cost of doing better is generally insane complexity), but it's just foolish to argue that they're anywhere close in performance in the general case.

Look, extraordinary claims require extraordinary evidence. Show me the big database servers running on microkernels. Show me the big web servers. Show me big mail servers. And show me how the performance compares to the monolithic kernel operating system on the same hardware.

Sure, microkernels "work", but who cares? I can get DOS to "work". Show me something that works *better*. Or to put it another way, when microkernels are truly better, you won't need to sell everyone, they'll sell themselves. So far, they haven't for general purpose operating systems that care about performance.

Re:Performance

[Anonymous Coward]

You've somehow translated "kernel" into "Linux kernel." The Unix and non-Unix kernels I've used over the past twenty years have pageable and non-pageable portions (even Windows does), so this distinction you make between what's possible in kernel and user code is an artificial one. You can trade off space vs. time efficiency wherever you put your code.

You assume that the FS or driver code you're writing is used infrequently enough that paging or swapping out its data structures is advantageous and inconsequential to performance, presumably on a single user system where only one process is occasionally calling the code. Hmm. This leads to a circular argument that performance doesn't matter in these circumstances.

You also imply that kernel code can't do I/O in large sizes, which makes me wonder how user code accomplishes this task if kernels don't support it.

Re:Performance

[Anonymous Coward]

we haven't even had reliable writing before this (not without the Windows NTFS driver).

The author's test results say that even the Windows driver in captive mode isn't reliable and crashes when he runs it (so his is the only reliable code). This is contrary to what you say here and to what I've been hearing elsewhere. What is people's experience in this area?

I thought I was safe using the captive NTFS driver.

Re:Performance

[Anonymous Coward]

"it's been a while but it seemeed to me that not only did linux read/write windows filesystems both on the same system and over the network faster than windows did, but that the reverse was also true!"

It is still true (except for NTFS that is). AFAIK the reverse was never true however, there is the illusion that that the ext2/ext3 driver for windows reads an ext3 partition faster but that is because the driver reads it as a ext2 partition and does not support the journaling. This bypasses the extra overhead the journaling gives but also bypasses the extra data integrity that caused you to choose ext3 over ext2 in the first place.

Re:Performance

[Anonymous Coward]

Dear god, not another micro versus macro debate. No amount of word twisting will change that fact that even when comparing theoretically perfect implementations of Macro and Micro kernels the Macro kernel will ALWAYS be faster performing.

A macro kernel does not have the overhead required to allow all of your independent pieces of functionally to communicate with one another. A macro kernel is equally easy for a developer to manage because logical division of code does not require seperation after compilation and runtime.

Security is another issue. A macro kernel reserves access to hardware and critical functions to trusted kernel code developed and tested by trusted sources. A microkernel requires interfaces that offload control to any malicious code that strolls along and takes advantage of it.

Re:Performance

[Anonymous Coward]

"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."

Uhhh... think SMB/CIFS performance compares...

Re:Performance

[nyri]

... is extremely bogus. ("Bogus" is a technical term. It means "completely wrong.")

So what does "extremly bogus" then means?

Re:Performance

[azhrei_fje]

Oh, I thought that was obvious: extrempletely wrong. :)

Re:Performance

[Anonymous Coward]

Dear god, not another micro versus macro debate. No amount of word twisting will change that fact that even when comparing theoretically perfect implementations of Macro and Micro kernels the Macro kernel will ALWAYS be faster performing.

Yes, but with a modern microkernel, the difference can be small enough to ignore. L4Linux (a Linux server running on the L4 microkernel), for example, is only about 4% slower than Linux, where as MkLinux (a Linux server running on the Mach microkernel) was typically much slower (around 50%, IIRC). Mac OS X also tends to be quite slow, owing to its Mach heritage (even though the BSD server is run in kernel mode, so the system is effectively monolithic).

If a superior architecture (superior in terms of security and robustness) produces a 50% performance hit, it can reasonably be argued that the trade-off has to be considered on a case-by-case basis, and may not generally be worthwhile (though some of us would still opt for the more secure/robust system). When that number falls to 4%, however, the argument for the inferior design ceases to be at all reasonable.

A macro kernel does not have the overhead required to allow all of your independent pieces of functionally to communicate with one another. A macro kernel is equally easy for a developer to manage because logical division of code does not require seperation after compilation and runtime.

It's mostly a matter of what you're used to. However, a microkernel is arguably easier to manage because each of the servers is isolated in its own address space, so a bug in one server can't cause another to mysteriously fail. Having done a fair amount of kernel mode debugging, I've found that bugs where one module corrupts data owned by another module are much harder to track down than bugs where a module corrupts its own data. Simply put, a monolithic kernel with loadable kernel modules has a much larger range of variations in the layout of the kernel address space than a microkernel (and with a microkernel, the server address space layouts also tend to be less variable).

Security is another issue. A macro kernel reserves access to hardware and critical functions to trusted kernel code developed and tested by trusted sources. A microkernel requires interfaces that offload control to any malicious code that strolls along and takes advantage of it.

This comment is patently absurd. Isolation of trusted modules in their own address spaces, with minimal rights granted to each server, is clearly more secure than throwing them all into the kernel address space. For example, if an audio server process is compromised, the attacker can make a lot of noise, but can't attack trusted modules in other servers, or in kernel mode. If a kernel-mode audio driver is compromised, the entire trusted base (kernel, drivers, etc) is handed over to the attacker.

Re:Performance

[fishbowl]

"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."

Are you making assumptions based on metrics? Are you willing to be something more than "your ass?"

Re:Performance

[Reality Master 101]

L4Linux (a Linux server running on the L4 microkernel), for example, is only about 4% slower [tudos.org] than Linux

The problem with this statistic is that it's where microkernel advocates consistently lie (including, alas, AST). 4% DOING WHAT??. Usually, that means it's 4% slower doing a single process test. Show me a test with dozens, if not hundreds of processes like you see on PRODUCTION servers, because that's where microkernels typically fall flat on their faces.

Re:Performance

[Anonymous Coward]

L4Linux (a Linux server running on the L4 microkernel), for example, is only about 4% slower [tudos.org] than Linux

The problem with this statistic is that it's where microkernel advocates consistently lie (including, alas, AST). 4% DOING WHAT??.

In this case, I believe the 4% number represents the compilation of the L4Linux server (the precise figure is 3.7%). An additional macrobenchmark used to compare the performance of Linux and L4Linux was the AIM Suite VII Multiuser Benchmark, which simulates a multiuser development environment. The slowdown in this case was 2.2% (which fell to 1.7% when the amount of memory reserved for L4 was taken away from the native Linux implementation), suggesting that for multiuser workloads, the performance penalty of using the L4 microkernel instead of a monolithic kernel is negligible.*

Usually, that means it's 4% slower doing a single process test. Show me a test with dozens, if not hundreds of processes like you see on PRODUCTION servers, because that's where microkernels typically fall flat on their faces.

Actually, the microbenchmarks, which focus on specific operations, were much more favourable to Linux than the macrobenchmarks like AIM, which attempt to simulate real-world workloads. This is just what one would expect, given that things like system call latency matter a great deal to benchmarks that focus on testing them, but are relatively unimportant to real-world workloads, because they represent a very small amount of the overall work done by the OS.

* http://os.inf.tu-dresden.de/papers_ps/sosp97_slide s.ps.gz

Re:Performance

[Anonymous Coward]

That would hurt the portability. I wouldn't be able to use it in FreeBSD.

Re:Performance

[cryptoluddite]

Yet the fact remains that user-mode NTFS is both faster and far, far more complete than kernel mode NTFS. There must be some explanation for it. It seems obvious that kernel mode drivers are too tedious and cumbersome to write effectively.

I do not imply kernel code can't do large IO, but rather that in general it won't have the features to recognize and combine IO as well as user-mode code will. The reason being that *all* code in the kernel has to be perfect so a lot of times you do not even attempt something complex without need. That's nice that you can make pageable kernel memory on some systems, but it doesn't change the fact that it's a PITA compared to user mode allocations.

Your point about swapping a swapping out dynamic data structures for the fs being for single user machines or being slow is pretty weak. For instance, if you insert all the file nodes into a hashtable then you have O(1) disk access to look up something in particular vs however many to locate it in a hierarchy like a btree for instance. So I'm not saying that it necessarily would be faster, but the concept certainly isn't guarenteed slower or only for single-process use.

Re:Yay

[Anonymous Coward]

gee and ntfs has remained completely static that whole time

This is great news

[scenestar]

Kudos to the devs.

This is one less barrier for linux interoperabillity taken away.

Maybe the fact that winfs was canceled is a good thing.

Re:This is great news

[bogaboga]

> This is one less barrier for linux interoperabillity taken away.

> Maybe the fact that winfs was canceled is a good thing.

Not so fast dude! I can almost guarantee that there will be an update to NTFS in the Windows environment that will introduce incompatibilities. We in the Linux environment will be playing catch up once again. Are we 100% sure that Windows Vista will use NTFS? I doubt.

This is good news though.

Re:This is great news

[MioTheGreat]

"Are we 100% sure that Windows Vista will use NTFS?"

Yes. The only change I've seen to NTFS is the addition of Transactional NTFS support, though.

Re:This is great news

[Teun]

Maybe this will bring WinFS back on the board...

Re:This is great news

[jZnat]

When I installed Vista Beta 2 on a friend's box, it required use of NTFS for its root partition (the C: drive as you Windows people like to call it), so I'd say that Vista will use NTFS. Then again, Vista might as well use Reiser5 or something, because that will be the default filesystem on Debian Stable kernels by the time Vista comes out.

Re:This is great news

[bogaboga]

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.

Re:This is great news

[Schraegstrichpunkt]

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:This is great news

[NutscrapeSucks]

One nice thing is that Microsoft can't change things willy-nilly with NTFS as it could with, for example, the Word file format

That seems wrong. Word files need to mostly work with a dozen different versions of Word. A filesystem really only has to work with a specific operating system and patch level. As long as there's seamless conversion, MS could change their filesystem as much as they'd like.

Although it's silly pananoia that MS would change NTFS just to defeat some useless dualbooting nerds -- NTFS is irrelevant in the places where Linux competition actually matters.

Re:This is great news

[Anonymous Coward]

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.

Re:This is great news

[puffing_billy69]

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

Nobody said they'd need to break compat with WinXP. You can be pretty sure the OSS NTFS driver != the WinXP driver. Changes could be made to NTFS that WinXP will survive, but the OSS driver will once again be "Dangerous" to write with. MS won't cop the blame, because it wasn't their driver that trashed it.

You can call it silly paranoia, but if I was motivated by Microsoft's profit margins, I'd do exactly the same thing, because I'm just as greedy and selfish. I'd design the FS primarly for lock-in, (implying covert changes to break compat), secondarily for integrity (because our users suck it up anyway), thirdly for speed.

Re:This is great news

[cbhacking]

Vista uses a new, backward-compatible version of NTFS. While it isn't the WinFS we've been hoping for, it does do some nice things like monitor changes to files and directories, and allow you to roll back these changes (literally, the most important parts of a versioning system. Not quite sure where it stores the rollback data, but my guess is in ostentatiously free space that is flagged in a special way). XP and even older Linux NTFS drivers are compatible with Vista's FS, but they are moving ahead... and I can't fault them for it. I would remind you also that Windows drivers for Linux filesystems are also playing catchup... here we have EXT4 coming out and the best Windows driver available is EXT2 (no journaling AT ALL).

Not Just Linux

[TheRaven64]

FUSE has been ported to FreeBSD, and it appears that the driver also works there.

Re:Not Just Linux

[foniksonik]

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:Not Just Linux

[tolan-b]

Unlikely, Windows tends to freak out if it wakes up with a different motherboard to when it went to sleep.. You might get it to boot but it would probably bluescreen before you got the chance to do much.

I was very impressed the first time I moved a linux disk to another box and booted it. The first boot it freaked out a bit, but on restarting it booted pretty much fine. A few config tweaks and it was happy as larry.

Re:Not Just Linux

[AlistairMcMillan]

But this depends on the Filesystem in Userspace (FUSE) kernel module which doesn't seem to be available for Mac OS X.

Remeber the driver layer in Mac OS X wasn't imported from FreeBSD, Apple developed their own called I/O Kit. http://en.wikipedia.org/wiki/I/O_Kit

Re:Not Just Linux

[xouumalperxe]

I can see windows not liking that. Too much hardware mismatch, possibly? Definitely a different video card between the two "machines", possibly different loads of other things (depending on how the virtualization is done). windows might throw a "different machine, won't boot" fit.

Re:Not Just Linux

[GlobalEcho]

Unlikely, Windows tends to freak out if it wakes up with a different motherboard to when it went to sleep

I don't believe the GP is proposing sleeping under the virtual machine and waking again in Boot Camp.

You might get it to boot but it would probably bluescreen before you got the chance to do much.

It would be easy, though, to allow the VM and Boot Camp to share many applications and user settings on an NTFS volume, as Windows is quite used to Active Directory and other ways of separating the user environment from the machine it is running on. Not Unix- or OSX-level separation to be sure, but it is there. That alone would save the majority of duplicated HD space between a VM and Boot Camp. The OS itself is probably less than 1GB.

It may even be possible to develop (on the VM side) some way of keeping "alternative" system files and executables around, to be substituted for the ones present on the NTFS partition as necessary so that the system behaves properly. An even better trick would be to make such a solution work with Windows Genuine Advantage (or whatever it is called) as well as FLEXlm and other license managers so that a single license for Windows and proprietary software will suffice for both installations.

It is worth noting that one thing you give up by having a VM use an actual partition is the incredible portability and duplicatability of VMs stored in a disk image.

Re:Not Just Linux

[Fez]

Even if it did manage to boot (which it might, if you're lucky) it would probably trigger the product activation routine, since the hardware has changed so much. That is, unless you're using a volume license copy that doesn't require activation.

Since SP2, we've had a lot more luck swapping motherboards and such and having Windows installs survive without needing a repair install. Sometimes it works, sometimes it doesn't. The odds are better lately, but it's still a roll of the dice.

Re:Not Just Linux

[tolan-b]

Well they did say they wanted to run the same copy of Windows on both.

Other than that yes I broadly agree with your other points. I don't know how feasible it is to share app installs across windows versions (can you share a registry?) but it'd be nice if you could.

Personally VMs aren't a huge amount of use to me at the moment. The only thing really keeping an XP partition on my box is Cubase, but unfortunately the audio drivers in VMWare aren't up to the task. Doubt they will be for the forseeable future either :(

Re:Not Just Linux

[Corbin Dallas]

Since SP2, we've had a lot more luck swapping motherboards and such and having Windows installs survive without needing a repair install. Sometimes it works, sometimes it doesn't. The odds are better lately, but it's still a roll of the dice.

From the research I've done, it is directly tied to the chipset driver used for the boot partition. If you swap motherboards, but the IDE or SATA chipset you're booting from remains the same, you'll have no trouble booting. Otherwise you need the repair, which re-wires the Windows install to load a different driver first.

Re:Not Just Linux

[ArbitraryConstant]

I don't see Apple being in a hurry to port FUSE to their kernel. They don't use the FreeBSD kernel, and it's too late in the release cycle of 10.5 to go around adding big new features to their own kernel.

Their NTFS support is just as bad as the Linux kernel's, so it does seem like something that might be useful to add to 10.6.

Re:Not Just Linux

[Tim Browse]

I changed the motherboard in my Windows machine once, but didn't reinstall the OS straight away - was curious if it would 'just work'.

I was running a dual boot Windows 98 and Windows 2000 system.

Windows 98 booted up and said "Crikey chief! It's all changed!", then had a bit of a scurry, and rebooted.

Then it did it again.

And again. And again. And again.

Then it worked.

After 5 reboots all my hardware had been auto-detected and configured, and Windows 98 was ready to go. I never had any problems with the installation after that.

Then I booted to Windows 2000. It crashed out in the text mode boot screens and died in a flaming heap, telling me I'd committed some heinous act or other. I never got it past that. In the end I did a clean install of Windows 2000.

I was impressed with 98, not so much with 2000. Surprising, as I'd fully expected the opposite result.

Re:Not Just Linux

[madsenj37]

Or as part of the 10.5.5 release. They need not wait until 10.6

Re:Not Just Linux

[timeOday]

That is interesting. I transfer linux systems from one computer to another often enough. It's just easier than a fresh install. For that matter, take the extreme example of Knoppix - a linux distro that not only boots, but works pretty darn well almost no matter what system you boot it on. It almost makes the idea of "installation" irrelevant.

Re:Not Just Linux

[evilneko]

Not so surprising, if you know much about Windows 2000. XP is the same way. It's an NT thing.

Re:Not Just Linux

[Anonymous Coward]

Windows 2000 does have closer ties to the hardware than 98. If you would have uninstalled all the drivers before switching out the hardware, W2k would have booted up with generic "safe" drivers, and then detected all the new hardware like the 98 installation did.

Re:Not Just Linux

[ArbitraryConstant]

True, but traditionally they don't put much enthusiasm into backporting features.

Re:Not Just Linux

[NutscrapeSucks]

I changed the motherboard in my Windows machine once,

It can be done, and there's some info out there on how -- basically, you have to delete the IDE device icon before you power it off.

Re:Not Just Linux

[ecliptik]

He's right, it's an issue with the IDE Drivers. Before you swap motherboards on a Win2k+ install make sure that the IDE driver in device manager is set to generic. Otherwise you'll get that dreaded STOP Error.

Here's a good link for it:

http://www.windowsreinstall.com/install/other/moth erboard/problems.htm

Re:Not Just Linux

[mczak]

That "heinous act" it told you must have been "inaccessible boot device".
For W2k and XP (not sure about NT) there are basically 2 drivers which it absolutely needs to be able to boot. One is the graphic driver, which has fortunately a fallback to generic VGA. The other is the disk driver, so if you change your board to one with a different hd controller (for typical setups that means different chipset, though you might get lucky if it's a different chipset but which can use the same driver, dunno) then it will not boot. There are documented ways around this (for instance in the MS knowledgebase), though yes if you ask me it's really lame that there is no generic ide fallback. Apart from that board swaps seem to work pretty well with W2k (even though not recommended by MS), of course you might need to change hal (uniprocessor to multiprocessor and such things) and other drivers later.
(Actually IME hd cloning / swapping is more problematic due to recognition of drives with some unique identifiers)

Re:Not Just Linux

[ischorr]

"I was very impressed the first time I moved a linux disk to another box and booted it. The first boot it freaked out a bit, but on restarting it booted pretty much fine. A few config tweaks and it was happy as larry."

I've taken the same Firewire HD and at different times booted the same install of OS X on a G5 iMac, a Mac Mini, and a 5-year old 533Mhz G4. This is the install that I use on a regular basis, and I have a lot of crap loaded...But it was 100% transparent to me that I was running the OS on a different machine. I suppose that's one advantage of having a relatively limited range of hardware that needs to be supported and a very solid driver base.

I agree though, Linux seems a bit more resilient than Windows in this area (though grub and lilo always seemed to freak out if I even did minor changes, like remove a CD-ROM. Making changes to partitions was much worse. I haven't really "used" Linux heavily in over a year so perhaps this has gotten better).

Re:Not Just Linux

[Antique Geekmeister]

This one is worth pursuing. Not only is FUSE amazingly useful for NTFS, it's handy for remote mounting filesystems via SSH, which is a very useful trick.

Re:Not Just Linux

[ArbitraryConstant]

"This one is worth pursuing."

I agree 100%. I'm just pointing out that Apple doesn't see it that way.

Re:Not Just Linux

[algae]

if you ask me it's really lame that there is no generic ide fallback.

There is. Go to the device manager and find your IDE controller. Click "update driver" and then manually choose a driver from the list. Select "Generic IDE DEvice" or whatever they call it. After this driver is installed, you can reboot the machine with a completely different motherboard.

Re:Not Just Linux

[mczak]

Yes that's true. But the point is that the generic ide fallback really should be automatic (as is the case with the vga driver).

Re:Not Just Linux

[the_B0fh]

Umm - people run vmware on native partitions and dual boot of that partition all the time, what in the world are you talking about? All you have to do is to set the boot profile up. And that's easy to do.

Re:Not Just Linux

[Anonymous Coward]

It can't. It is loaded by the bootloader. (Maybe there should be a bootloader option like /BASEVIDEO, say /BASEIDE).

No 64-bit

[Bill Dimm]

Looks like a great piece of work. One important note from the article:
Problem: Why doesn't the driver work on 64-bit and bigendian systems?
Answer: We have no resource for that. Neither hardware, nor workforce.
Status: Low priority.

Re:No 64-bit

[david.given]

Problem: Why doesn't the driver work on 64-bit and bigendian systems?

Yeah, but... 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? In fact, these days you'd pretty much have to go out of your way to ensure that it didn't work. Particularly for user-space code.

Has anyone actually tried this yet?

Re:No 64-bit

[Megane]

You have to go out of your way to make sure it doesn't work, unless you're dealing with binary files on a disk that you didn't write, you have no guarantee that they are of the same endianness as the CPU you are running on at the moment. (this is a valid issue for cache files, etc. when creating multi-CPU binaries for OS X) Actually this is the other way around, as you know the NTFS file system is always little-endian, but now you have to do extra work to read it.

I suppose if you wanted to create a new NTFS file system and didn't care if it worked on any other computer, you could go ahead and let it create a big-endian NTFS, but that would be rather pointless.

Re:No 64-bit

[david.given]

You have to go out of your way to make sure it doesn't work, unless you're dealing with binary files on a disk that you didn't write, you have no guarantee that they are of the same endianness as the CPU you are running on at the moment.

Only if you were reading those binary data structures in an incredibly stupid way --- i.e., by fread()ing them into a structure. And frankly, if you do that, you're incompetent. These days, the way data's encoded on disk is completely irrelevant to the way it's stored in memory. This sort of thing has been known about for years.

Re:No 64-bit

[Tim Browse]

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.

Re:No 64-bit

[Anonymous Coward]

Assuming your reverse-engineering is complete. If you don't know completely what the data structures are, but you do know if you write values into position XYZ, it happens to work. That's how Samba worked for years.

Re:No 64-bit

[david.given]

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).

uint32_t read32bit(off_t offset)
{
uint8_t buffer[4];
fread(buffer, 4, 1, disk);
return buffer[0] | (buffer[1]<<8) | (buffer[2]<<16) | buffer[3]<<24);
}

{
uint32_t value = read32bit(offset) & 0x1FFFFFFF;
}

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.

Re:No 64-bit

[ModMeFlamebait]

Well, what do you suggest? getc() or scanf()?

Re:No 64-bit

[Anonymous Coward]

So you're saying reading four bytes from a file into a uint32_t will magically take care of any endianness for you? Care to try that again?

Re:No 64-bit

[Briareos]

Problem: Why doesn't the driver work on 64-bit and bigendian systems?
Answer: We have no resource for that. Neither hardware, nor workforce.

I suggest someone get them an NSLU2 from Linksys - they retail for 80EUR here and have a 266MHz ARM CPU that can run in either little or big endian mode, with several distributions of Linux already available to install on them...

np: Duo505 - Facing It (Live) (Monsters Of Morr Music)

Re:No 64-bit

[Tim Browse]

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.

Re:No 64-bit

[david.given]

So you're saying reading four bytes from a file into a uint32_t will magically take care of any endianness for you?

Well --- given that you get to specify what order you put those bytes together to make the uint32_t, then yes, it does.

Re:No 64-bit

[david.given]

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

Hardly --- you have four bytes on disk, you want to put them together to form an integer, how else are you going to do it? { int i; fread(&i, 1, 4, fd); } ? I'm sorry, but that's grotesque hackery; it's making all kinds of assumptions as to the size of int and the encoding used, and while people did do that kind of foulness in times past, these days we know better. I stand by my earlier statement; if you do that sort of thing, then you've been either badly taught, or do not care about writing good code, and either way, it's deeply unprofessional.

Re:No 64-bit

[waveclaw]

Problem: Why doesn't the driver work on 64-bit and bigendian systems?

I can confirm that it compiles, installs and works on 64-bit SuSE Linux 10.1 (AMD Athlon(tm) 64 Processor 3000+.) It does require you to get the latest 2.5 fuse (http://fuse.sourceforge.net/). And I do have a complete 32-bit environment installed, but the ./configure was clearly x86_64.

# arch
x86_64
# uname -r
2.6.16.13-4-default
#lsmod | grep fuse
fuse 39192 2
# /usr/local/bin/ntfs-3g /dev/hda1 /windows/C -o rw,user
# cd /windows/C
# ls
# touch autoexec.bat
# ls
autoexec.bat


And I am just one checkinstall away from an rpm. (Too lazy to write yet another custom SPEC file today.)

Re:No 64-bit

[linuxrocks123]

So send them a patch. Put up or shut up. Right now, you're just being sanctimonious and annoying. But after your patch is incorporated, you'll be a hero to all the many, many people who DESPARATELY NEED to access NTFS data on their Linux SPARC machines.

Re:No 64-bit

[Rich0]

I doubt many SPARC users will care, but I'm sure many of us amd64 users wouldn't mind having our platform supported as something other than an afterthought.

If you're going to read and write files or network streams, you shouldn't be using data types like int/etc. Use the defined-size types, and then you don't have to worry about portability! It is just something that needs to be kept in mind, and it doesn't have to be a hardship. Plus it saves a shower of patching after the fact...

Re:No 64-bit

[Anonymous Coward]

You forgot us PPCACs. We're not dying :(

Re:No 64-bit

[ErikZ]

Yes, you'll be a hero to Ralph to the end of time.

Re:Yay

[Anonymous Coward]

What's the last closed-source file system you completely reverse-engineered, then?

Awesome!

[The MAZZTer]

Except that every partition tool under the sun fails on my NTFS drives, so I can't even install Linux anywhere... so my computer is STILL Linux proof.

Re:Awesome!

[lord_rob the only on]

A reply from the developper :

Currently I'm not interested in the kernel driver. It's a lost case for over a decade. Full read-write could be done in user space pretty fast and I can't see drawbacks, only benefits:

- NTFS is huge and complex, not for the kernel. Crash in kernel (hw error, corrupt ntfs, etc) and game is over. Crash in user space then just restart the service.
- kernel has a lot of limitations, restrictions which are all gone.
- fedora/redhat users have never ending hassles with installing the driver. Instead they could install ntfs-3g once and forget the issue forever.

Re:Awesome!

[foniksonik]

Huh? Never thought to simply put in an extra drive? You can dual boot off two separate hard drives.... Just put your fancy new NTFS reading Linux drive as master.... and use a standard Linux dual boot app to pick windows when you want it.

Re:Awesome!

[rthille]

Try booting a live linux CD, then using 'dd' to zero out the first 16K of the disk.
Then reboot from the CD and reformat the drive.

Sometimes the partition software can get confused by what's there, and the kernel will cobble up reasonable information about the drive from the drive's response itself.

Of course if you want to preserve your NTFS partition that's not a good approach. However, I've had bad luck with resizing windows partitions, so my approach is to backup, reformat, reinstall, and reload from the backup.

Re:Awesome!

[ABoerma]

SUSE's intaller YaST let me resize NTFS partitions. You might want to try that.

Re:Awesome!

[Bill Dimm]

Have you tried the latest GParted? This article says a new version was released on July 9.

Re:Awesome!

[Mini-Geek]

- NTFS is huge and complex, not for the kernel. Crash in kernel (hw error, corrupt ntfs, etc) and game is over. Crash in user space then just restart the service.

But Windows XP has NTFS support in its kernel, why can't Linux?

cue the "yeah but that's why Windows crashes all the time" flames...and if they're right, then what's the big difference between having FAT32 support and having NTFS support?

Re:Awesome!

[ratboy666]

How to do it...

Assuming partition tables are "fubar".

#1 BACK UP ALL YOUR DATA. This is normally a sign of a failing drive.

#2 Download and burn a bootable CD of you hard drive vendors diagnostic kit.

#3 Run it, and "recertify" your drive. May take a couple of hours (and, you may just want to dumpster the drive, if your time is valuable). If the drive does not certify, discard it.

#4 Boot your system with Knoppix, or another recovery Linux system. Issue the command: "dd if=/dev/zero of=/dev/hda" (replace hda with hdb, hdc, hdd, etc. depending on which hard drive it is).

#5 Run Linux partitioning tool "fdisk /dev/hda". You *will* get a complaint about an improper partition table, which is ok. Partition, and write the new partition table.

#5b Alternatively, boot a Linux installation CD, and load Linux. Ignore warnings about "improper partitioning", and choose to have the partition table replaced.

The IMPORTANT steps are 1 to 3. If the partition table cannot be manipulated, it is an almost sure sign your drive is heading south.

Ratboy

Re:Awesome!

[OmnipotentEntity]

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!

[lord_rob the only on]

But Linux has ext[2|3], reiser[3|4], XFS, JFS, ... in its kernel, why can't Windows ?

Re:Awesome!

[0xception]

they can but they just dont want to... why would they enable their competition?

Re:Awesome!

[Anonymous Coward]

But Linux has ext[2|3], reiser[3|4], XFS, JFS, ... in its kernel, why can't Windows ?

As far as I'm aware, the ext2/ext3 drivers for Windows do run in kernel mode, as do the BSD FFS drivers (I don't know if XFS, JFS or reiser drivers have been written). The difference is that these are open source file systems, so it can be known that a port to the Windows IFS (Installable File System) interface is correct. NTFS, on the other hand, is closed, and only Microsoft know what will change with each new release, so the correctness of any reimplementation is questionable. Even so, a well written NTFS driver should still be able to run in kernel mode on Linux: running in user mode doesn't add anything of value unless the driver is prone to crashing.

Re:Awesome!

[LinuxGeek]

Help is all around!

Re:Awesome!

[jZnat]

Maybe Microsoft has never heard of those filesystems? I've noticed that most BSD and other UNIX-like distros use their own filesystem instead of using Linux's main filesystem (ext3), so Windows is just doing what many distros do. I'm quite sure that most of said distros support other filesystems, but insist on using its native filesystem for things like root and boot.

Re:Awesome!

[Dave2 Wickham]

Actually, it's not quite that simple; Windows (2000, at least) doesn't like it if it's not on the primary HDD. You have to make Windows think it is on the primary HDD to allow it to boot. In GRUB it's a case of adding the following lines:

map (hd0) (hd1)
map (hd1) (hd0)

Not a major change, but without knowing this beforehand, you can't just get Windows to boot off a secondary HDD.

Re:Awesome!

[Anonymous Coward]

Yeah, and you CAN shoot yourself in the foot, so why don't you?!!

Re:Awesome!

[trifish]

> It's still in beta. While it's a GPL'd beta

Out of curiosity: How does a regular beta differ from a "GPL'd beta"?

Re:Awesome!

[gowen]

Regular beta's eventually come out of beta.
GPL'd betas just gain an incredibly stable core with unstable advanced features continuously in flux.

Re:Awesome!

[mortonda]

Ubuntu was able to resize and repartition my ntfs drives perfectly...

Re:Awesome!

[Schraegstrichpunkt]

ntfsresize doesn't work for you?

Re:Awesome!

[Anonymous Coward]

use the file system tools iwth windows to clear the errors

Re:Awesome!

[LSD-OBS]

Well, #4: dd if=/dev/zero of=/dev/hda bs=512 count=1

Since the main partition table lives only in the first sector of the drive (along with the MBR & boot loader). Saves a lot of time this way, especially if DMA has not been enabled (which still seems to happen quite often!).

Re:Awesome!

[Geoffreyerffoeg]

That's assuming the problem is with the partition table. I'm not sure about grandparent, but on my desktop, ntfsresize declares a bad sector somewhere in the drive and says it would be "unsafe" to partition. Whereas Windows Scandisk doesn't see anything wrong.

And no, I'm not about to pay $50 for PartitionMagic to install a "free" operating system (dualboot, so it doesn't even give me the karma of no Windows).

Re:Awesome!

[Anonymous Coward]

(Please note this post is sarcastic, imitating parent's style ...)

Re:Awesome!

[julesh]

NTFS is still in flux as Microsoft is still developing it.

From where I'm sitting it looks as though they haven't released an update for nearly 5 years now. That's not exactly what I'd call highly active development.

Re:Awesome!

[urbanRealist]

For a little more detail on this suggestion, check out my grub.conf:

default=0
timeout=10

splashimage=(hd0,0)/grub/ splash.xpm.gz
title Gentoo Linux 2.6
root (hd0,0)
kernel /kernel-genkernel-x86-2.6.12-gentoo-r6 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev nosmp
initrd /initramfs-genkernel-x86-2.6.12-gentoo-r6

title Windows XP
rootnoverify (hd1,0)
map (hd0) (hd1)
map (hd1) (hd0)
makeactive
chainloader +1

Re:Awesome!

[ratboy666]

This means that there is a bad spot on your drive. You are sitting on a "timebomb". Run SMART tests and see if that gives more information (it should give a log of the failure).

The drive stills needs to be recertified. And, above all else, BACK IT UP. Most of the drive vendor recertification diagnostic utilities will overwrite the drive, destroying its data anyway (did I mention BACKUP?).

The "OS" here is not material -- your DRIVE is failing.

Now, if you have a backup, reinstalling should be a breeze. Any reasonable backup utility will let you restore to a different media size. I am not a Windows Backup Expert; but I do know that Windows 98 came with a backup utility that created backup sets over the network -- I imagine that (and a boot floppy) should do the trick. I don't really know, because all data on my machines is network mounted anyway, to RAID5 storage. And, the Windows installations are in virtual machines anyway (except for one machine, which is a complete "destructo" box, anyway). Which I do because I don't ever have the time to "reinstall" Windows, and I am not a Windows Certified Anything (so I can't/won't troubleshoot problems -- I take "reboot/re-install" as the primary resolution to problems with Windows).

I cannot emphasize enough the need to recertify or trash that drive. Its like ignoring strange sounds out of your card. Hard disks are sensitive mechanical things.

As always, YMMV -- this is just advice

Ratboy.

Re:Awesome!

[Geoffreyerffoeg]

I would agree with that if any other tool complained about the drive. Why only ntfsresize?

Re:Awesome!

[ratboy666]

Again, I am *not* a Windows expert. I would boot Knoppix from CD, and run:

badblocks /dev/hda

This will read the drive, and report any bad blocks. In Linux, the results of this can be fed to the make file system utility, which can then skip using those areas (for really bad areas).

Did you do a "surface scan" under Windows? (I believe the default is a file scan).

Ratboy.

Time to change my main partition...

[the_humeister]

...from usmsdos to ntfs! Finally!

Re:Yay

[Anonymous Coward]

Still years before NTFS will be documented. And Microsoft doesn't supply a ReiserFS or Ext3 driver even though those filesystems are documented.

Re:Not as good as it claims to be

[Anonymous Coward]

What ntfsmount can do?

        *
            Resize files. (Always work.)
        *
            Create files and hardlinks. (This will either succeed or it will be refused, 50-50% at the moment. Up to about 10 files can be created in a directory.)
        *
            Create directories. (Same as above.)
        *
            Remove files/directories (Works fine or removal will be refused, 90-10% at the moment.)
        *
            Operate with special Interix files (symlinks, devices, FIFOs and sockets.)

this is from their wiki.. really.. no thanks

This is off-topic, but...

[reynaert]

Can anybody explain why SourceForge's mail archive uses such freaking huge text? This can't be what SourceForge's web designers intended, but I don't have this problem on any other website, so I doubt it is a local problem.

Re:This is off-topic, but...

[Anonymous Coward]

because sourceforge is a piece of shit?

Re:This is off-topic, but...

[Anonymous Coward]

Does anyone find it annoying when they try to download something from sourceforge ? You click download... you get the list of mirrors... you choose a mirror, the 'your download will start shortly' page comes up.. then your download starts. Did you really want it to start ? No, you were just looking for the link so you could paste it into a terminal window for download. Why ? because the link listed on the original download page won't work because it requires you to choose a mirror and command line download tools don't really know how to choose a mirror. It seams like a lot of process just for one download. Don't these bandwidth saving measures seam a little 1995 ?

Re:This is off-topic, but...

[Anonymous Coward]

No problem heare, check your browsers font settings. Why are your browser icons so big and ugly?

Right click on them, select cusomize, check the use small icons check-box and hit done.

Re:This is off-topic, but...

[jZnat]

Your font setting for monospace might be odd. Check it out, and make sure to check all the languages if it seems okay at first.

Re:This is off-topic, but...

[Ant P.]

They screwed it up with the new layout. It used to work fine for me too.

Re:This is off-topic, but...

[baadger]

They're not, that's exactly what Firefox looks like by default.

WRONG - ntfs-3g != ntsfmount

[Chris Pimlott]

This new driver is "ntfs-3g". "ntfsmount" is the previous NTFS driver that ntfs-3g is based on. Since ntfs-3g is brand new, most of the documentation on the Linux-NTFS site is about the older driver. ntfs-3g promises practically unlimited file creation and deletion.

Cue drumroll for New! Improved! MS file system

[dpbsmith]

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.

Re:Cue drumroll for New! Improved! MS file system

[Anonymous Coward]

Two points:

1. The likelihood that anyone at Microsoft cares about whether or not Linux can read and write to NTFS is vanishingly small. If anything, a good NTFS driver for Linux means more people who dual-boot will use NTFS for their shared partitions, which might be marginally good for Microsoft.

2. From what I've read, WinFS (which stands for Windows Future Storage, not Windows File System) isn't a new file system at all, just a set of database services that run on top of NTFS. That's why Microsoft were able to delay it until after the Windows Vista release, since it can always be added to a Windows Vista system later on, without any changes to the underlying (NTFS) file system.

Re:Cue drumroll for New! Improved! MS file system

[_KiTA_]

"Oh, that's not WinFS. They just renamed NTFS2 to try and cover their asses and screw with people's heads. Fortunately we're all well informed here so we didn't fall for that one, eh guys? *nudge nudge*"

How hard is that?

Re:Cue drumroll for New! Improved! MS file system

[Anonymous Coward]

I think you'll find they did NTFS as
a. FAT is/was too lacking in features needed for the NewTechnology
b. As a branch from HPFS on OS/2
In fact wasn't it MS that invented file system drivers whilst all the Unix system of the time stuck to UFS & various flavours of?

Re:Cue drumroll for New! Improved! MS file system

[KingArthur10]

Microsoft Windows Live WinFS Enterprise 2007. That sounds more like a Microsoft naming convention.

Re:Cue drumroll for New! Improved! MS file system

[schmiddy]

This is the cue for Microsoft to roll out a new! improved! disk directory format.

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.

Re:Cue drumroll for New! Improved! MS file system

[simdan]

-Perhaps someday MS will be forced to play catch-up with us for a change.

You mean like how they have been playing catch-up with Firefox?

Re:Cue drumroll for New! Improved! MS file system

[evilviper]

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.

And they'll call it NTFS6...

They already did something like this with NTFS5, found in Windows 2000. Once Windows 2000 has booted-up with access to an NTFS partition, you can't run chkdsk from NT4 (or older) anymore. You're actually stuck with 2000, whether you like it or not. God help you if you remove your Windows 2000 installation.

Personally, my hopes lie with FFS Drv. Absolutely EVERY major operating system other than Windows can read/write to UFS/FFS.

Re:Cue drumroll for New! Improved! MS file system

[Cal Paterson]

-You mean like how they have been playing catch-up with Firefox? You mean like he mentioned in his post?

Re:Cue drumroll for New! Improved! MS file system

[simdan]

Doh, my bad.

Re:Cue drumroll for New! Improved! MS file system

[Anonymous Coward]

If I were Microsoft, I'd make just enough undocumented changes to screw up reverse-engineered implementations of NTFS...

Then they'd get done over the EU for more anti-competitive behaviour, and all the Microsoft fangirls would whinge and bitch that Microsoft were being picked on.

Re:Not as good as it claims to be

[Anonymous Coward]

Windows users are used to this, though. Remember the FAA even had procedures in place to reboot their Windows boxes regularly since they would crash every 49.7 days (or was it minutes). I'd say "about ten" will about double the effectiveness of NTFS compared to the primary vendor(90% joking).

Re:Not as good as it claims to be

[Anonymous Coward]

The limitations you reference are for linux-ntfs. This thread concerns a new project with the same goals that may or may not be merged into linux-ntfs in the future, but is "capable for unlimited file creation and deletion", according to this exchange between the respective developers

http://sourceforge.net/mailarchive/forum.php?threa d_id=23836054&forum_id=2697

Um...

[Ayanami Rei]

Windows 2003 x64 is pretty common.
If I were dual booting a 64-bit platform that would be my Windows-OS of choice.

Re:Um...

[EXMSFT]

It's not THAT common. Yet.

Why?

[matt me]

What drew you to using NTFS on your drives? That data is destined to obsolete itself. No other operating system can write to it ( Linux, BSD, Mac OS X, you name 'em) can write to it. Nor can older versions of Windows (98, ME). That leaves only Windows 2000 and XP. Vista may well stick with NTFS rather than WinFS, but the installer won't let you install over XP, but demand to reformat the target disc.

But other operating systems can *read* NTFS, so you can just copy it off, format the drive to a better file system, and put the data back.

Re:Why?

[SirTalon42]

1.) WinFS was canned a good while ago
2.) Despite its name, WinFS is NOT a new file system, just a layer on top of NTFS.

"Works" - 50/50

[ozbird]

It might be fully open source, but it isn't fully working yet. From their Wiki:

What ntfsmount can do?

• Resize files. (Always work.)
• Create files and hardlinks. (This will either succeed or it will be refused, 50-50% at the moment. Up to about 10 files can be created in a directory.)
• Create directories. (Same as above.)
• Remove files/directories (Works fine or removal will be refused, 90-10% at the moment.)
• Operate with special Interix files (symlinks, devices, FIFOs and sockets.)

At least it is unlikely to cause filesystem corruption now.

Re:"Works" - 50/50

[Anonymous Coward]

Yes, ntfsmount doesn't look very useful to me.

It's good job we're talking about ntfs-3g, which is a different and much improved FUSE driver that is an improved version of ntfsmount. ntfs-3g does not have those limitations. The developer even posts performance figures that he obtained using bonie++: he's tested ntfs-3g by creating tens of thousands of files and directories.

Is it stable?

[rsilvergun]

as I recall, the problem with the kernel driver is it's not considered safe for writing. There's plenty of antecdotal evidence that it's ok to write, and I've done it, but has the been run through it's paces?

Re:Is it stable?

[slightcrazed]

This isn't a kernel driver - this is a userspace utility. You are correct that the NTFS driver included in the linux kernel does not have reliable write ability, but this has nothing to do with the kernel NTFS read driver.

Re:Is it stable?

[megari]

Depends on what you mean by reliability. The driver shouldn't cause corruptions even when writing, but refuses to create or delete files as that functionality is still unimplemented in the mainline (a fully-functional kernel driver is supposed to be released summer 2007).

ntfsmount != ntfs-3g

[Chris Pimlott]

ntfs-3g is brand new and it not the same thing as ntfsmount, which is what the current documentation covers. Please read the ntfs-3g announcement, which promises practically unlimited file creation and deletion.

Re:ntfsmount != ntfs-3g

[Schraegstrichpunkt]

If you read the announcement, you'll find that there are still bugs (at least that's the way I interpret it). However, they're bugs that Windows chkdsk will find and fix.

The next big step for the driver will be when it can mark the filesystem as "clean", so that chkdsk doesn't need to be loaded.

Please note that, this being a Slashdot post, I could be totally talking out of my ass here.

It is good news ... But ...

[vtcodger]

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:It is good news ... But ...

[Martin Blank]

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:It is good news ... But ...

[peragrin]

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.

Re:It is good news ... But ...

[Anonymous Coward]

for what it's worth, linux supports fat32, and they didn't change that to block out support.

Re:It is good news ... But ...

[Anonymous Coward]

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.

And if that "one update" is made, sysadmins the world over will be screaming for Microsoft's blood because the mission-critical server that doesn't get updates installed until they've been vetted carefully suddenly can't read files created by the boss's laptop that he updated at home.

Yeah, right.

Sorry, but all this "ZOMG MICROSOFT IS TEH EVIL!!! AND CAN BREAK STUFF BY UPDATES!!!!!111" crap is just paranoia. The day Microsoft deliberately and secretly breaks compatibility is the day Microsoft shoots its own genitals off. And Microsoft may be unethical, but it isn't stupid.

Re:It is good news ... But ...

[samkass]

"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."

This is pure FUD. The entire reason Microsoft is the most successful business in the world is that they stay compatible with more stuff for longer than anyone else. (In many cases in practice, it's the other folks staying compatible with them, but it's the same issue.) In any case, they're not going to go and break forwards compatibility with previous versions for a long, long time.

There are lots of reasons to dislike Microsoft and distrust their software, but this isn't one of them.

Re:It is good news ... But ...

[tfinniga]

I think the more possible danger is to ever-so-slightly modify the format, such that the current reverse-engineered driver will fail to work, but their stuff will continue to work, because they have more guarantees or limitations in the filesystem than could be deduced from the first attempt at reverse engineering.

For example, if I were looking to create a system that would be hard to reverse-engineer, I'd do something like add flags all over the place. If the flag was on, it would behave one way, if it was off, it would behave another way. Leave all the flags off in release versions. Then, if someone is able to duplicate the original behavior, release an update that starts turning on the flags, exposing the different behavior in old systems. Then wait until the system is reverse-engineered again, and start flipping a different flag.

While that's a little paranoid, it's possible that such a thing could happen by accident - say, they build in advanced features that almost never get used. I didn't even know that symlinks were possible in NTFS until a few months ago. Are they fully supported by this driver? What if the next version of office starts using symlinks all over the place? Or Vista uses them to store search results?

Re:It is good news ... But ...

[puffing_billy69]

and Microsoft is going to think really, really hard before they go and do something that may result in lost data.

I really must give this Widows software another try. I hear with Vista they're not only going to include security with their products, now you say they're going to thing really hard about what they do in their OS as well!

Seriously, they will think really really hard, they always have. But it's always been more in the interest of their bottom line, not mine or yours.

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.

I can't believe how many years it's taken to reverse NTFS. What does that tell you about a filesystem? It must be so deliberately convolted, arcane and obfuscated to have taken so much effort. The idea of storing data in blocks in a linear address space is nothing new, but somehow I don't think MS stopped when they got a working ACL-based hierachy, otherwise reverse engineering could have been done in a week.

Re:It is good news ... But ...

[puffing_billy69]

The entire reason Microsoft is the most successful business in the world is that they stay compatible with more stuff for longer than anyone else.

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.

Re:It is good news ... But ...

[wolrahnaes]

Right, but they tried to pull some shit with patents.

Re:It is good news ... But ...

[Antique Geekmeister]

They *tried*. WinFS is XML based, with a stack of Microsoft patents. If WinFS had turned out to work in Vista, they would have released it and started breaking every Linux repartitioner or password changer or image changer they could manage to screw up.

Fortunately, WinFS seems to have been scrubbed. But very minor changes in NTFS, labeled as "enhancements", could still be integrated into Vista or the next OS release. It's certainly a potential problem that shouldn't be ignored.

Re:It is good news ... But ...

[Antique Geekmeister]

No, Microsoft deliberately breaks compatibility. I suggest you look at the old FreeDOS lawsuits, and the Netscape lawsuits where Microsoft tried to pretend that NT Workstation couldn't work as a Netscape server, the oddness of Internet Explorer and their refusal to make it removable, and the weirdness they did to Kerberos that MIT sued them successfully over, and even take a look at what Active Directory does to DNS, and the current lawsuits about ODF in Massachusetts, and the recent EU lawsuit whaere Microsoft refused to document their software, instead publishing deliberately obfuscated and unusable documentation.

Re:It is good news ... But ...

[Mr. Shiny And New]

Well, to be clear about the Windows NT Workstation bit: It's the LICENSE that prohibits using it as a server, not "Microsoft breaking compatibility". Also, refusing to make Explorer removable has nothing to do with compatibility with any software; I've ALWAYS been able to use Netscape or Mozilla or Firefox on any version of Windows that I cared to. Now, some programs DEPEND on IE, but that's not because Microsoft is breaking compatibility with Netscape. Finally, ODF isn't about Microsoft breaking compatibility; they never had it in the first place; it's about MS fighting to stay in the list of "legal" office suites to use in MA.

Your list of gripes are all about maintaining a monopoly, but frankly they have nearly nothing to do with compatibility. MS's version of Kerberos isn't compatible with any other? True, but at least it's not like they HAD a compatible version, and then they broke it on purpose. And if someone DID reverse-engineer the AD protocol, MS isn't likely to make drastic changes, at least not to the existing installations.

I dislike MS as much as the next guy, but you have to respect the lengths they go to to keep software working. Read Raymond Chen's blog
http://blogs.msdn.com/oldnewthing/ if you want to know just what kinds of things they've done to make sure your crappy game from 1994 or your business-critical software that was written for NT 3.51 still works.

Re:It is good news ... But ...

[Anonymous Coward]

WOW what a complete piece of FUD. winFS still had full backward compatibility for ALL the old methods of NTFS access. hence it would have broken NONE of the linux repartioners or password changes. The XML part sat as a layer above the NTFS filesystem, not in it.

If you are going to create fud at least make it believable.

Re:It is good news ... But ...

[Curien]

Nonsense: NTFS is a Windows Filesystem. It's never had to be compatible with anything else

It has to be compatible with unpatched Windows systems. Many people format their portable storage devices as NTFS. Does MS really want to start getting a flood of calls asking why some computers can read the drive and some can't?

Re:It is good news ... But ...

[puffing_billy69]

Now read my second paragraph.

Re:It is good news ... But ...

[Curien]

You anticipate backward compatibility, but we already know that the OS filesystem routines have only very limited /forward compatibility/ with future NTFS versions. It's not like we have to wildly guess at this stuff -- ntfs.sys is sitting right there on each XP box.

But don't let sound reasoning stop you from continuing your Chicken Little impression.

Re:It is good news ... But ...

[puffing_billy69]

but we already know that the OS filesystem routines have only very limited /forward compatibility/ with future NTFS versions.

Exactly. My point is, whatever forward compatibility XP NTFS has, you can be sure isn't already in the OSS NTFS. It's only stable because it's worked so far. Whatever (as yet unused) forward compat in the current NTFS is exactly the leeway immediately available. Any movement will break OSS NTFS, but not XP. In the meantime, XP can be patched with another NTFS with more goodies.

Re:It is good news ... But ...

[Curien]

Changes of such a small nature are easy to work around. No one performs mission-critical tasks with reverse-engineered fs drivers anyway, so changes to the system are acceptable. Its only use is as a stop-gap in emergencies (eg, for data recovery or platform migration).

Re:It is good news ... But ...

[skaya]

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.

Yes and no -- they must stay backward compatible with the currently deployed versions. That gives a comfortable time window (for instance, if M$ were to decide today to introduce a new filesystem "feature", they would probably give patches for WinXP and 2K3, but not for 2K ; and by the time everybody applies the patch, we can only hope that the Linux NTFS project will catch up with the new "features").

Re:It is good news ... But ...

[Martin Blank]

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.

Re:It is good news ... But ...

[Antique Geekmeister]

I'd count the NT Workstation licensing restrictions as "breaking compatibility": they were clearly not based on limitations of NT Workstation itself, since Workstation was in fact the same as Server with just 2 registry differences.

IE, I see your point, but IE's unremovability breaks vendor's ability to install the browser of their choice. It came up, harshly, in their more recent anti-trust lawsuit in front of Judge White.

The ODF issue is also one where I see your point. It's more a reflection of Microsoft's insistence on proprietary technology, rather than actively beaking what used to work for someone else.

Kerberos, however, was pretty blatant. It completely fractured the use of Kerberos with anything but Microsoft-based releases by misusing a reserved field for their own "extension" purposes. That can't be accidental. It caused a real pain for vendors of network based storage and for maintainers of Kerberos networks who wanted their UNIX or Linux and Microsoft systems to use a single sign-on system, and it helped cause a real corporate push over to Active Directories and its version of Kerberos at the expense of interoperability. Fortunately, the MIT and other Kerberos developers were able to publish patches to work around the brokenness, but it wasted a lot of time and caused a very serious lawsuit with MIT.

Re:It is good news ... But ...

[Mr. Shiny And New]

You're right about the NT Workstation limitation being due to a registry entry, but my point is that it's not about "compatibility". Microsoft sold people an OS to use for workstations. They made it clear that the OS was not for use as a server. They sell a different OS for servers. Naturally they didn't want people running Netscape server on NT Workstation because it violates the license. Microsoft would have been thrilled to sell you NT Server for you to run Netscape Server. But their EULA forbids doing that on NT Workstation (at least, it forbids more than 10 connections at once). Whether or not that is "right" or "moral" is beside the point, their product, their license. Nothing to do with compatibility. The same restrictions would apply to Oracle or even IIS running on NTWS.

Again, the IE thing wasn't about any compatibility. Microsoft used OEM licensing agreements to ensure that OEM Vendors didn't install Netscape; if they installed netscape MS wouldn't give them a fair price on Windows licenses. However, if they DID install Netscape, it would work 100%. Sure, you couldn't REMOVE IE, but its presence never harmed Netscape (except that people didn't strictly NEED Netscape since a browser was already installed). No compatibility involved. Lawsuits yes, compat. no.

Finally, Active Directory didn't break existing Kerberos implementations. It was a new "protocol" based on kerberos. Now, it's designed to be different than Kerberos, i.e. it's designed NOT to be compatible with Kerberos. But I think that's different than if MS HAD kerberos, then CHANGED it (thus BREAKING compat). Since MS never had Kerberos before, how could they be accused of breaking anyone's compat by introducing pseudo-kerberos? You didn't have Kerberos before, you don't now. Yes, it's mean spirited, but it's certainly not the same as what everyone expects them to do with NTFS: change the implementation so that Linux, or any other third parties who write ntfs, suddenly are corrupting data because they think it's ntfs but don't realize it's new-ntfs. Or less maliciously, suddenly just can't write to the disk because the format has changed and they don't know how to do it. I mean, there has to be a practical benefit to this. There are almost no use-cases for NTFS-access in Linux, why would MS care if people are doing it? Dual boot systems? Please, that's like 1% of 1% of the population. Rescue disks? Ok, but MS doesn't compete in that market. How much would MS have to spend to introduce major, compatibility-breaking changes into NTFS JUST to break people's rescue disks?

Re:It is good news ... But ...

[Lord Kano]

Microsoft is going to think really, really hard before they go and do something that may result in lost data.

You must not have been around for Double Space.

LK

Re:It is good news ... But ...

[vtcodger]

***This is pure FUD. The entire reason Microsoft is the most successful business in the world is that they stay compatible with more stuff for longer than anyone else.***

I think maybe you are trying to say that Microsoft generally supports their old formats. Which is true with a few exceptions -- e.g. newer Windows versions don't support NBF (NETBIOS) message traffic unless it is wrapped in TCP/IP.

What you actually said is not correct. Microsoft tends to have fairly limited support from Microsoft for anything MS did not invent. Take file systems for example. Windows XP supports FAT12, FAT16, FAT32, NTFS. It might or might not support the two Windows 9 era compressed file systems (DRVSPACE). I'd guess that it does, but since I have as little to do with NT based windows as possible, I'm not sure. Linux, OTOH supports all of those (albeit NTFS is a bit shakey). It also supports umsdos (fat32 with Linux permissions), ext2, ext3, netware, Reiser, probably minix and a bunch of other stuff.

More important, I think it would be a mistake to take historic MS as a model.

Two reasons:

First, Microsoft Itself has changed with time. Few folks remember, but MS's selling point in the early 1980s was OK products at reasonable prices without copy protection. They still have OK products, but the prices have escalated and copy protection has reared its very ugly head.

Second, Microsoft today is not the Microsoft of say 1993. MS 2009 or MS 2012 or whenever will be yet another company. The MS cart is no longer the only stall in the marketplace to acquire software that does the basic stuff business and home users need. I personally don't think Linux is quite up to even Windows 98. But it's close, and I could live with it if I had to. (In fact, I am, by chance, posting this on Firefox under KDE on Slackware 10.2 although I usually use an old Pentium with Windows 9). Emulation and WINE are eroding the absolute need to have an MS OS. Extrapolate those trends. What you will see is an MS that is no longer able to lock in users through improved products (or at least the illusion of improved products). What's the next logical step? My bet is that they will lock in users by means of proprietary data formats that hold the user's data hostage. What other choice will they have?

Re:It is good news ... But ...

[vtcodger]

I was thinking in terms of a scenario where in say June of 2009, a routine looking Windows Update changes NTFS to write directories in a new format -- for valid security or performance reasons of course. Good Heavens, Microsoft wouldn't deliberately break Linux. Oh heavens no. How could anyone think such a thing? Old format directories are still accepted of course, but they are changed to the new format when rewritten. Windows users don't see any difference. But Linux users can't access any file in any directory where a file has been updated.

The Linux folks labor mightily and by early August, there is a new NTFS driver that handles the June directory format. ... except that the July 20th Windows updates make another change to the directory format. ... You can work out the scenario from there.

Just in time!

[Anonymous Coward]

For the new WinFS features in Vista to make it all incompatible again.

Oh, right. :-)

Duality

[Data Link Layer]

Cha Cha Cha Cha Cha Cha. See In The World Of NTFS The One Who Can Run Linux And Windows Is King.

EVEN BETTER NEWS

[dsginter]

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?

Re:EVEN BETTER NEWS

[hackstraw]

A given distro can now come with a handy Windows InstallShield Wizard and INSTALL UNDER WINDOWS and BOOT/SHARE the same partition.

Is this new?

I may be delusional, but I thought there was a way years ago via loadlin.exe and something like umsdos filesystems under linux, and booting and sharing between the two was theoretically possible. I never tried it, but I vaguely remember such a thing.

Also, InstallShield is a good brand name, but from what I remember in working with it, and using it, it was not a panacea. Any recent Linux distro that installs linux today is pretty straight forward. Put CD in CD-ROM, boot from CD, hit return and answer some basic questions. About the same or easier than Windows from what I remember.

Re:EVEN BETTER NEWS

[andreyw]

Loadlin and its Win9x relative are as much history as the DOS-based Windows.

Re:EVEN BETTER NEWS

[petermgreen]

I may be delusional, but I thought there was a way years ago via loadlin.exe and something like umsdos filesystems under linux, and booting and sharing between the two was theoretically possible. I never tried it, but I vaguely remember such a thing.
windows is a moving target.

with win9x you could happilly use loadlin in your autoexec.bat and umsdos to run linux with no repartitioning and no touching special disk sectors.

nowadays things aren't so rosy, its possible i belive to persude NTLDR to load linux but the method i belive the method is a bit tricker than just using loadlin under win9x's version of dos through autoexec.bat and you can always fall back on using your own MBR without too much issue.

most new pcs are now using NTFS (for good reasons, it supports permissions and larger individual files both of which were annoying limitations of fat). Unfortunately this makes it a little trickier for linux to share windows's space. The UMSDOS approach has never been done for NTFS (probablly due to a lack of an adequate NTFS driver, image files are another option (and have been supported on NTFS partitions for a while though all creation and resizing of the image had to be done from windows or using something like captive) but are a bit restrictive (you have to manually set asside a lump of hdd for linux). Full partitioning is even more restrictive (partitions can change ids as you add and remove them and any reallocation means at least two seperate resize operations one of which will likely involve signficant time spent moving data).

Re:Yay

[Elektroschock]

Good point, I wonder why they don't. The reason is of course anti-open source ideology. But I believe MS has a business case here to support ReiserFS

As far as I understand NTFS will be laid open because of the ruling of EU competition authorities. Now MS pays millions a day because they do not comply yet.

And anyway, as a business you should write to your competition&antitrust office and complain.

---
What is regulation in the US like: When you take the original MS Windows source code and document it, may others use your documentation?

We always could write to NTFS

[r00t]

dd if=/dev/zero of=/dev/hda1

It's really fast, despite being in userspace, though it can still take a while because there is so much that it needs to do. Start it before you leave work, or before you go to bed.

As a side effect, your NTFS partition will finally be free of spyware. It's the only way.

Re:We always could write to NTFS

[Anonymous Coward]

That driver sucks! I tried it on 3 different computers and it didn't work on any of them.

Re:We always could write to NTFS

[RogL]

I say we dust off, ssh in and dd if=/dev/zero of=/dev/hda1 it from orbit. It's the only way to be sure.

Re:We always could write to NTFS

[hackstraw]

It's really fast, despite being in userspace

Yeah, I guess this was funny, but being a stickler for details and an ubergeek, this is what I would do:

dd if=/dev/urandom of=/dev/hda1 bs=size_of_cache_on_hd

urandom is of course more predictable than an infinite set of zeros. Also, the bs= parameter is MUCH faster than doing it one character at a time (the default for dd). YMMV, with the size of bs but the cache size on the disk seems reasonable to me, maybe a little less, but something greater than 1 byte at a time.

Also, I was being silly with the predictable part, but also using dd is almost exclusively in kernel space, not userspace (hence, the need to be root). I hope the parent was being funny there as well.

Good luck in destroying your drive more efficiently :)

Re:We always could write to NTFS

[MSG]

It's really fast ... though it can still take a while

You contradict yourself. It's really slow, and can take a while. The default block size is very small, which is very bad when you're writing blocks of data to a hard disk, synchronously. Use a larger block size, like 4MiB, for much faster completion:

dd if=/dev/zero of=/dev/hda1 bs=4194304

Re:We always could write to NTFS

[42forty-two42]

Tack on a bs=1024768 or so for signifigantly faster results ;)

Re:We always could write to NTFS

[r00t]

Well, everything winds up in kernelspace at some point.

The blocksize should matter little. Linux has fast system calls and does not normally do uncached access to block device files. (Linux has no real character device files for disks. You could use O_DIRECT in the open call, or use rawsetup to associate one of the obsolete /dev/raw* devices with a normal device. This is not normally done.)

I doubt the default block size is "1c". (one character) I could believe it to be "1b", which is 512 bytes. It's also reasonable for dd to use the preferred IO size from a stat() call, which would be 4096 bytes or larger. As usual, GNU shit doesn't come with a man page. The disk itself can't accept writes as big as the cache size. IDE can accept up to 128 blocks, which is 64 KiB.

Re:Yay

[sud_crow]

No, they dont supply one.
But there is a third party implementation using their (MS) development tools:

http://www.fs-driver.org/

Alternate Data Streams

[Anonymous Coward]

Anyone know if this works with ADS (Alternate Data Streams)?

Re:Yay

[lixee]

neither does Apple!

Re:My thoughts on this...

[tomhudson]

Too bad he wasn't more honest and said "just STEAL your ideas from everyone else and call it a Unix operating system" You're all nothing but fucking thieves!

Well, you've been stealing ideas about communication - you've stolen most of the alphbet, some punctuation, even some html formatting codes, to create your post. Couldn't come up with something original? To use your own words, "You're nothing but a fucking thief!"

(actually, you're JAW - Just Another Wanker)

Re:My thoughts on this...

[mh101]

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.

r00tkits

[mnemonic_]

It is very interesting that posts which lack any real insight are modded up liberally as long as the author sounds friendly and the post is made early.

Re:Yay

[Lehk228]

filesystem drivers are not like office document filters, 99.5% correct is great for documents, if the filesystem driver is 99.5% it's still dead wrong and will screw up your machine

Still using FAT32

[Anonymous Coward]

I am still using FAT32 on my Windows XP machine. I heard that NTFS is better, but I havent dare to use it. Because DOS dont support FAT32, and if something happends, then if I am using NTFS, then it will be a bitch to recover the data.
I wish Microsoft would open up the specs for NTFS... :(

Re:Still using FAT32

[Anonymous Cowled]

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...

Re:Still using FAT32

[Master of Transhuman]

Everybody knows NTFS is superior to FAT32 - BUT FAT32 is FAR more compatible with Linux - until now, anyway.

And even now, I'm not switching my Mandriva 2006 to this driver and converting my Windows FAT32 partitions to NTFS until this thing has had a nice shakedown - and has been included in the next Mandriva and other distro releases.

I'm not chancing that this thing will trash my Windows partitions and leave me screwed when I need to be supporting a client on the Windows side of the machine.

Let's all remember the geniuses at Fedora who never tested Fedora Core 2 with a dual-boot system and a lot of people ended up not being able to boot Windows after installing. Sure, for most savvy people it was an "easy" command-line fix and no data was lost - once somebody figured out the problem - but for a lot of people it was a major pain in the ass.

Re:Yay

[Schraegstrichpunkt]

Isn't ReiserFS GPL-licensed? Microsoft would probably have to license the code from Namesys (or release Windows under the GNU GPL -- fat chance!). I have no idea what they (Namesys) are charging.

Re:Yay

[Schraegstrichpunkt]

Crap. I used <blockquote> where I meant to use <p>.

'Preview'? On Slashdot? You must be joking, right?

Re:Yay

[Jesus_666]

Microsoft only licenses something when they can't buy the company...

That's a pity

[Darkforge]

... because there is a really good reason to support NTFS in the kernel: so you can boot off of an NTFS drive. That would eliminate the need for Windows users to re-partition their drives when installing Linux, and allow for an easier dual-boot.

Re:That's a pity

[bfree]

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.

Re:That's a pity

[Anonymous Coward]

So, uhm, stick the required libs and progs in initrd and mount the silly thing as /.
Assuming grub/lilo/whatever knows about it (or use a normal /boot partition).

Re: My stealing of this...

[Jesus_666]

That's because we're all evil thieves (chaotic evil, actually). Yup, Linus Torvalds is a level 15 Thief/Wizard specializing on Thievery:Copyright Infringement. After we have stolen Windows we will proceed to steal Christmas, the fire and your time. (Then again, we already are doing that last part, via this very site.) But we aren't done yet. After we're done stealing Microsoft we will steal Bill Gates' thoughts from his mind and sell them on the black market. Which we will also steal.
Now excuse me, I have to go to my (obviously stolen) kitchen and steal me a sandwich. The flavor is peanut butter crime.

Re:My thoughts on this...

[Jairun]

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:Yay

[Anonymous Coward]

Only 10-12 years after NTFS was launched?

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. Needless to say, however, NTFS has changed with each new version of NT.

Personally, I think Microsoft should offer NTFS drivers for other operating systems, or at least provide full documentation to people who'd like to write them. Features like journalling and ACLs may have been exciting in 1993, but they're fairly common now, so I don't think NTFS provides any important advantages over alternative file systems on other platforms.

The case for offering NTFS is as simple as this: the more people that use NTFS to store their data, the more data there is that is accessible by Microsoft Windows, without any further effort on Microsoft's part. The ubiquitousness of FAT was probably helpful to spreading Microsoft's DOS/Windows platform (later supplanted by NT), and at worst it was neutral. Now that rivals have caught up with NTFS in most of the important ways, why not make it ubiquitous too?

use ext3 in windows instead

[radarsat1]

I found I prefer simply being able to access my Linux partition from Windows by installing the (unfortunately not open-source) Ext3 driver.

Seems to work quite well.
Yes, unfortunately it can't be Windows' root partition, but at least I can use Windows & Linux without needing an EXTRA data partition, or using Windows on FAT32.
(Though I usually do just use FAT32 to keep things easy, because I'm not all that worried about security on my home box.)

Anyways one problem I ran into using a shared FAT32 partition is that I couldn't use files > 4GB. Haven't seriously tested it yet but I think using the Ext3 driver will fix that. (Mainly for virtual machine images for Qemu.)

Steve

Re:use ext3 in windows instead

[bazorg]

I was wondering if anyone would point this out. Perhaps what I do with my files is unusual or something, but my simplistic point of view is that NTFS allows >4GB files and is exclusive to the Windows world and FAT32 is read/writeable by a lot of different OSes but doesn't allow files that large nor file access permissions.
When I'm dualbooting Windows and Linux and/or using windows inside a Vmware virtual machine, I would need to be able to reach "/home" or "My documents" from different places, and I have to use FAT32. Now being able to use one of the Linux-compatible filesystems is great - much better than keeping a FAT32 partition with important stuff on an iPod or on a laptop hard drive. Thanks for the link to Ext2 IFS.

Re:use ext3 in windows instead

[cortana]

FYI, ext2fsd is a Free Software alternative to the fs-driver.org IFS.

Re:use ext3 in windows instead

[radarsat1]

Cool! I think I've heard of it.. how does it perform in comparison?
Is it just as good?

Re:use ext3 in windows instead

[cortana]

I've never tried the non-free IFS so I can't compare them. It is 'fast enough' however. I think after that point performance becomes meaningless because you're not going to be constructing a high performance file server using ext[23] in Windows; you're just trying to access your Linux filesystem when booted into Windows.

Re:use ext3 in windows instead

[qwertyatwork]

Ive used it for a couple of months and no problems. Works well. Install it, and from cmd you type "mount 0 (0 is ide0, 1 would be ide 0 slave 1 etc) 2 (partition 2) e: (where you want it to mount). Ive never used the write function though. Windows writing to ext2 scares the hell out of me. I mount them all read only.

Does a good job - needs more testing and funding.

[wmaster]

I have successfully installed and tested it on most recent Debian Sid/Kanotix with kernel 2.6.17 - http://kanotix.com/. Creating and deleting folders (even in root directory), adding more than 100 files to a folder and deleting them again, removing some 100 temporary files, copying a 1,7Gb sized iso-file and moving it around - all that was possible whithout any error. A very promising initiative from a developer to get things moving again in this mine field of myths. As he is a true open mind he contacted first the existing ntfsprogs-project and handed all his work over to them - just a pitty that the head developer there recently started to work for Apple, and announced that he is not interested in getting a solution for Linux out, before he finished the same for his new employer next year. I would be more than happy to support the ntfs-3g developer getting his own project running, and also finding sponsors in order to solve this nasty hardware problem. Anybody interested in helping? ;-)

Personally never understood why people always make

[msimm]

this same argument. I'm glad for NTFS support myself, but a Linux recovery disk is definitely not the best solution for actual systems recovery. And were did we all seem to get this idea that Linux bootable disk were the only bootable disks anyway?

I'd suggest taking a good long look at UBCD4WIN. Its *is* a bootable disk. It runs the Windows kernel of your choice (you build it off your own disk, but the process is much less painful then it sounds). It also happens to include a slew of native Windows programs/utilities for doing things like...password blanking, virus/spyware detection/recovery, partition recovery/disk repair, Windows networking, including SMB access for recoveryies where you can't get the core functioning but still need to retrieve those files.

It is an all around good project and I'm sure I'm not even remotely doing it justice. Of course best of all, its native NTFS (assuming you build XP or a variety that supports it) so you don't have to worry about write problems in the same way.

I work as a systems admin at a mainly Linux shop so I don't get much cause to use it, but its something I'd never leave home without. I'm sure I've got a Knoppix disk sitting around somewhere, but for (Windows) system repair there's simply no advantage.

I sound like a commercial. :) Donate some money or something if you find it useful. Its free after all, but the guys time can't be.

FUSE is too slow

[caseih]

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.

Re:FUSE is too slow

[Sterling Christensen]

That was probably captive-ntfs. The benchmarks show how much faster this is comparaed to captive.

Re:FUSE is too slow

[caseih]

nope, it wasn't captive. Captive was definitely unbearably slow. I'm glad this new driver is faster, but it still will never be fast enough to use as a primary partition due to fuse.

Re:FUSE is too slow

[LocalH]

Who in their right mind would use NTFS as a root fs for any *ix OS? That's about as smart as wanting to use UMSDOS for your root.

Re:FUSE is too slow

[cr0sh]

That's about as smart as wanting to use UMSDOS for your root.

Late to this, but I had to reply: have you ever heard of "MonkeyLinux"? That was the first form of Linux I played around with (oh, back in 1995/96 timeframe) - it pretty much does (more or less) exactly what you said.

Yeah - it sucked...

Now it's time to...

[ivan256]

In the grand tradition of open source NTFS drivers, this project has now reached the point in it's lifecycle where the developers abandon it and all future implementations start from scratch.

Re:My thoughts on this...

[Anonymous Coward]

You are fucking retarded, that is the worst attempt at trolling I've ever seen.

Go and slit your wrists, preferably with an axe or buzzsaw, so that you'll destroy the nerves and never again be able to use a computer without lots of extra difficulty. Yes, you really are THAT bad at trolling.

I went that route as well.

[HoneyBunchesOfGoats]

I use a large ext3 partition to store video files, as I'm experimenting with video editing in both Linux and Windows. No hiccups so far using the ext3 filesystem for big video files in Windows. One thing to be aware of, though, is that Windows sees it as ext2, so you lose the benefits of the journalling filesystem there. I haven't lost any data yet, but it is something keep in mind.

Better have a full fledged EXT3 for Windows

[gd23ka]

Why not take the filesystem driver completely out of the hands of Microsoft and use an EXT3 filesystem on windows instead?
I already looked into this and there's one open source filesystem driver that is read only and the other one is rw, free as
in beer, but is otherwise closed source and doesn't handle their ACLs and other extended attributes they might have.
There would definately be a place for a migration kit for upgrading Windows to full featured EXT3.

With EXT3 people have a proven filesystem. I don't know what people have with NTFS but the way I see it, it is best not touched
because it is undocumented and subject to change as "(Microsoft) business needs" dictate.

Re:Better have a full fledged EXT3 for Windows

[maximander]

If I'm taking me windows machine off of NTFS, I want to be switching to reiserfs (or 4), not ext3.

Re:Better have a full fledged EXT3 for Windows

[Anonymous Coward]

The ext2 drivers I've dried on NT were a one-way ticket to bluescreens. I have little faith in the ext3 drivers to be any better.

should have run sysprep

[Anonymous Coward]

large organizations that clone windows to dozens of differents of kinds of machines use sysprep and a cloning program, like norton ghostcast, to instantly propagate a single windows build (including various other programs, like quicktime, acrobat, etc) to hundreds of diverse machines at once.

Ubuntu Install

[Aladrin]

If you want to install this, you'll need FUSE 2.5. (K|X)Ubuntu only has 2.4, so you'll need to get an update.

http://www.debuntu.org/2006/06/26/71-fuse-253-for- ubuntu-dapper/

I've installed that on my desktop machine and managed to mount my ntfs drive (for dual boot) and read files. I didn't try to write anything yet, though. It seems to work fine.

Enjoy!

Re:My thoughts on this...

[Anonymous Coward]

If that was the worst troll ever, what does it say about the five people (including you) who replied to it?

Some hope for me...

[rrohbeck]

Maybe it'll help me fix the damaged filesystem on one of my machines. CHKDSK /F doesn't help. There's a directory that contains garbage, among it a file named con :(
Gotta try it next week in the office. Otherwise it's "reinstall XP" time.

Re:Yay

[julesh]

Random aside:

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, ...) 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.

So, when Vista flops, what are MS going to replace it with?

Re:Yay

[db32]

Ok...so...just would like to point out. You are on slashdot....talking about filesystem drivers...and you think that is what SINGLE stands for? You sir should get a +1 Funny :)

clarification

[petermgreen]

sorry one paragraph in that comment wasn't very clear

replace

nowadays things aren't so rosy, its possible i belive to persude NTLDR to load linux but the method i belive the method is a bit tricker than just using loadlin under win9x's version of dos through autoexec.bat and you can always fall back on using your own MBR without too much issue.

with

nowadays things aren't so rosy, its possible i belive to persude NTLDR to load linux but the method i belive the method is a bit tricker than just using loadlin under win9x's version of dos through autoexec.bat however you can always fall back on using your own MBR without too much issue so this isn't the main problem.

Will the real moron please stand up.

[Anonymous Coward]

"...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..."

Some people not living in their mom's basement actually have to use more than one OS.

Personally I would LOVE to have solid, stable, reliable R/W NTFS access from Linux. The reason being that I could then format my external USB/FIrewire drives with something other than FAT32. I'm sick and tired FAT32's limitations. In particular it's filesize limit.

I'd like a filesystem that I can use on Win boxes without installing drivers on them, and still use on my Linux boxes.

Meanwhile, you're the idiot. Now go away, I think I hear your mom calling you for dinner.

Tachyon

Re:Personally never understood why people always m

[Master of Transhuman]

Yup - Ultimate Boot CD For Windows is based on Bart's PE, with additional utilities.

As a PC tech support guy, I couldn't live without it.

It could use some improvement, but then it is being improved all the time. The last version I got, though, had some issues with some of the utilities.

You can even put this thing on a (large - 1GB) USB key and boot Windows from the USB key (IF the system BIOS allows it - which most clients PC's don't, unless they've very new.)

Re:My thoughts on this...

[Anonymous Coward]

Meh, I was just talking out of my ass, I wasn't really sure it's a troll, i figured it could also be a methhead, or something like that. or an agent provocateur, but if it actually is just someone really crazy, it's better to not acknowladge the possibility that they're not a troll because that probably has a much better chance of making them feel bad/making them understand just how hillariously pathetic they are.

It doesn't count as feeding a troll if you say something purposely to the troll, not to whatever fake person the troll is pretending to be.

The odd thing was that someone modded this insightful, 99% chance that it was the poster of that message, in which case metamoding, as I understand it, will make them regret it.

Just tried it out...

[pxc]

And it works fine. The only problem is that SuSe 10.1 doesn't load the fuse module before it tries to mount the fstab, so after I boot I have to do a "modprobe fuse" and "sudo mount -a" to get it to work...

PS: I've tried both ntfsmount and captive-ntfs on this same system and neither have worked.

Re:Just tried it out...

[krischik]

I have a similar problem with firewire attached storrage. I just moved the mount commands into: /etc/init.d/boot.local

which allways served my well for tricky a file system mounts.

Martin

Re:Steps in the right direction

[LocalH]

And what's wrong with that for legacy compatibility? Non-FAT32 filesystems are the defaults, and that's the way it should be. What, would you rather no modern OS even support reading FAT32, much less writing it?

OT: FFS

[LocalH]

I saw FFS and thought "since when can any major OS read the Amiga's FastFileSystem?"

Re:OT: FFS

[evilviper]

Yeah, we've long since reached the point of recycling TLAs.

You misunderstand

[einhverfr]

The problem is that you have to be able to execute the stream somehow. This means at least a reference to it somewhere. In practice this means at least a registry entry or something like that.

Otherwise the stream never gets executed.

Re:You misunderstand

[Vo0k]

A registry entry, a buffer overflow, a trojan binary replacing standard with minor modification, a system service called with unusual parameters...

Most safely the buffer overflow. Buffer overflow vulnerablities are considered dangerous in apps that have access from outside or run at elevated privledges. Networked allow remote access, elevated mean access at higher privledges. Local userspace overflow means no profit - it's just a fancy method of launching a program, if you can do this through local overflow, you can do this directly through startup files (registry, scripts.) Nobody checks notepad.exe for buffer overflows. And few expect a local file's creation date field to contain an exploit...

Re:You misunderstand

[einhverfr]

I don't know about you but I do check these things regularly when I have to run Windows, and if I saw something unusual like Notepad.exe running from a startup script, I would be very suspicious.

Re:You misunderstand

[Vo0k]

It doesn't have to be a startup script. It may be launched by common use or a standard startup program - explorer.exe, winupdate, one of several dozens of programs that briefly launch on startup - or programs that simply are commonly used - msword, outlook (okay, this one is networked so gets scrutinized), msphotoedit (default picture viewer), media player (xbox got hacked because media player didn't check for validity of its font files), "archived folder manager" (built-in compressor), or whatever a joe average is likely to click within first 20 minutes of work on his peecee.

They won't work on PCs of users who don't use this kind of software, but these users are usually too advanced to be worth the risk. The rootkit only cares to remain -undetected- on all PCs, not necessarily running. It's about the size of the botnet, not about access to one specific PC.

BTW, heard about that hellish trojan from ancient times? It was compiled into the login process, granting a backdoor. But if you wanted to recompile the login binary, it was also included in the C compiler, changing the sources of the login program on the fly, plugging itself during compilation. And if you were really paranoid and wanted to recompile the C compiler from sources, it would patch the sources of the compiler as well, infecting the new binary. No amount of scrutinizing the sources or startup scripts would reveal it. But it's still possible. Replace windows update binary, replace any of startup binaries, replace some of the built-in security software, break any known antivirus while it installs, and the only thing that changes is md5sum of given binary, but then even md5sum.exe can be modified to return fake sums of modified programs and itself once you install it. The limit would be only the range of "supported" programs, one day a new antivirus would be released and old versions of the rootkit wouldn't detect it, it would notice system files notified (unless OS file access API wasn't modified and the rootkit just bypasses it...) and the rootkit would be detected. But on most systems running common software it would remain undetectable.

rfsd: ReiserDriver

[hitchhacker]

Now all we need is a Windows driver for Reiser...

Ask and you shall receive:
rfsd: ReiserDriver

though I havn't tried it yet... of course.

metric

Wrong scenario

[einhverfr]

They could "update" data structures in future operating system releases. Of course this means that the current driver would still work for older Windows versions.

For example, Windows NT4 SP3 could not read an NTFS partition created with Windows 2000.

Re:Wrong scenario

[DMNT]

And to add an insult to an injury, Windows 2000 and XP will automatically transform any NTFS disk to the current NTFS version if one is ever connected. So you never can swap disks between two versions of NT tree.

Re:My thoughts on this...

[Anonymous Coward]

"Where the fuck is the innovation?"

Good question. NTFS was just another technology Microsoft bought. Like the NT kernel, DOS, MS Anti-spyware, and everything else of even slight merit from MS that they didn't simply steal.

Knoppix is your friend

[einhverfr]

It will give you read-only access to your NTFS partition on XP. I have used it for a lot fo data recovery jobs.

Re:Knoppix is your friend

[Antique Geekmeister]

Amen. I use it for file recovery of trashed systems all the time. But with a usable NTFS *write* capability, it can even incorporate something like the "chntpw" tool, used to reset passwords on Windows boxes with its own bootable CD.

Even better, this new NTFS writing capability will allow us dual-boot users to safely put our grub or LILO created boot record for dual-boot machines into a file on the NTFS boot partition that allows easy use of the Microsoft boot loader to slect operating systems. That way, if we have to scrub our Linux partitions, we don't have to go nuts trying to restore Microsoft's boot loader. It will also allow us to put files on the NTFS partitions for casual storage when we run out of space on our Linux partitions, for things like downloading music or DVD images or CD's. (Only ones we legitimately own, of course!%B1!)

Re:Steps in the right direction

[Anonymous Coward]

Indeed, FAT32 is a requirement so that computers can read/write flash memory cards over 2GB. I wouldn't want my digital camera or MP3 player to be stuck at 2GB just so that the firmware authors don't have to implement a whole new complicated filesystem!

dom

Re:My thoughts on this...

[Anonymous Coward]

NTFS was just another technology Microsoft bought.

Er, no. NTFS was developed at Microsoft, by Gary Kimura and Tom Miller.

I've heard there are a few similarities to HPFS, the OS/2 file system, but this was also developed at Microsoft, by Gordon Letwin and others, and the two file systems are very different overall, with HPFS lacking many of NTFS's features (such as journalling).

As an aside, it was during the development of HPFS for OS/2 that Microsoft came up with the idea of implementing the file system as an Installable File System driver, rather than writing it into the kernel itself, as had traditionally been done. The idea was conceived by Mark Zbikowski, of MS-DOS fame, and I believe he was awarded a patent for it.

Re:Yay

[conufsed]

Well... it can't be too long before linux kernel 2.7 gets branched in preparition for Vista's replacement. Linux 3.0

Does this mean another delay in Vista?

[aevans]

Does this mean another delay in Vista so that they can add the WinFS DB backed file system back? Microsoft hates Samba at least as much as any other open source project.

Re:Great news. (v2.0)

[darkonc]

* Install linux on a different physical harddisk and unplug it whenever you use Windows. Maybe put the least used one on an external hd.
* Use a bootable linux-cd, like Knoppix for daily work.
Okay, both of these are very unpractical...

I've been there.. I've installed a knoppix CD image on an external drive in a USB enclosure. I can then use a (modified) Knoppix CD that uses 'fromhd=/dev/sda5', to finish the boot from USB.

I've also installed a CD image on my main box, and setup GRUB to boot from it.
I can then mount /home/knoppix from another partition (in KNOPPIX/knoppix.sh) (or even the same partition if I remount the CD image partition R/W and load any extra packages from either the CD (safest) or the HD partion (more convenient). I've used that kind of setup for my basic desktop CD for most of this year (Just switched to a real ubuntu setup this month for various technical reasons).

Updates are a breeze -- I copy the latest Knoppix CD to another partition, copy in the extra DEB files and setup a GRUB stanza. One nice thing about it, from a security standpoint, is that the compressed disk image is relatively hard to compromise (and easy enough to check from the CD miniroot if I want to be paranoid).

As a proof-of-concept, it's been pretty effective. If I move the setup to an external USB HD, and combine it with a (credit-card sized) knoppix boot CD, then I've got a fully portable knoppix desktop. If I put it on a 2" laptop drive, then I can fit the whole thing in my shirt pocket. (( I'm currently using a full-sized USB enclosure)).

(note to self: always always always do at least one preview before posting).