Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Fully Open Source NTFS Support Under Linux 310

Posted by CowboyNeal from the long-time-coming dept.
lord_rob the only on writes "The Linux NTFS project has released a beta version of its fully open source userspace (using FUSE) 3G-Linux NTFS support driver. According to the developer, this driver beats hands down other NTFS support solutions performance-wise (including commercial Paragon NTFS driver and also Captive NTFS, which is using windows ntfs.sys driver under WINE)." That's right, writing to NTFS even works. Soon it'll mean one less recovery disk to keep around, I hope.
This discussion has been archived. No new comments can be posted.

Fully Open Source NTFS Support Under Linux More

Fully Open Source NTFS Support Under Linux

Comments Filter:

  • Great news. (Score:5, Interesting)

    by LinuxGeek ( 6139 ) * <djand...nc@@@gmail...com> on Saturday July 15, 2006 @10:35AM (#15724485)
    This gives us another tool that can be used to repair windows systems that have been hit by some of the newest rootkits [f-secure.com] 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. (Score:2, Interesting)

      by maxume ( 22995 )
      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. (Score:5, Informative)

        by Vo0k ( 760020 ) on Saturday July 15, 2006 @11:19AM (#15724615) Journal
        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. (Score:5, Insightful)

          by cnettel ( 836611 ) on Saturday July 15, 2006 @11:27AM (#15724658)
          You can come with quite clever ways to hide data. The point is that the rootkit, to be an infection, must also have some way for a standard Windows routine to actually read that data and load it as code. In practice, it means that the real, non-rootkit-mangled, version of the registry will probably contain a reference, or that the normal data stream of some system binary will be changed as well.
          • 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.
          • 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 [infosecwriters.com]

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

            Scary stuff :-).

            Jeremy.

    • Re:Great news. (Score:5, Informative)

      by Tim C ( 15259 ) on Saturday July 15, 2006 @11:02AM (#15724559)
      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.
      • 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. (Score:5, Interesting)

        by Thing 1 ( 178996 ) on Saturday July 15, 2006 @02:14PM (#15725159) Journal
        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. (Score:4, Insightful)

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

    • Re:Great news. (Score:2, Informative)

      by 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,

    • It is good news ... But ... (Score:5, Insightful)

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

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

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

      • Re:It is good news ... But ... (Score:5, Insightful)

        by Martin Blank ( 154261 ) on Saturday July 15, 2006 @12:26PM (#15724836) Homepage Journal
        But, keep in mind that NTFS remains proprietary and Microsoft can break it for newly written files any time it suits their business purposes to do so. All it takes is one update.

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

    • EVEN BETTER NEWS (Score:3, Interesting)

      by dsginter ( 104154 )
      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?

  • Nothing for you to see here. Please move along. (Score:4, Funny)

    by roger6106 ( 847020 ) on Saturday July 15, 2006 @10:35AM (#15724489)
    Nothing for you to see here. Please move along.

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

  • Performance (Score:5, Interesting)

    by Reality Master 101 ( 179095 ) <RealityMaster101@gmail. c o m> on Saturday July 15, 2006 @10:40AM (#15724500) Homepage Journal

    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.

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Saturday July 15, 2006 @11:16AM (#15724602)
      Comment removed based on user account deletion

    • Re:Performance (Score:3, Insightful)

      by jrcamp ( 150032 )
      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.

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

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

    • Re:Performance (Score:2, Interesting)

      by zataang ( 596856 )
      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 nee

    • Re:Performance (Score:2, Insightful)

      by iamacat ( 583406 )
      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 (Score:5, Informative)

        by azhrei_fje ( 968954 ) on Saturday July 15, 2006 @01:22PM (#15725002)
        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 (Score:4, Interesting)

      by ArbitraryConstant ( 763964 ) on Saturday July 15, 2006 @12:55PM (#15724923) Homepage
      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...
  • 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.
    • > 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 (Score:4, Funny)

        by jZnat ( 793348 ) * on Saturday July 15, 2006 @11:37AM (#15724686) Homepage Journal
        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 (Score:4, Insightful)

          by bogaboga ( 793279 ) on Saturday July 15, 2006 @11:47AM (#15724711)
          The `beef' is not whether Vista will use NTFS. The concern is that even if it uses NTFS, there will be an update to this NTFS that will "force" Linux into catch-up position. Guys, this develpoment is not in Microsoft's interest. Remember what happenning to Samba with CIFS/SMB? The underlying protocol remained basically intact but Microsoft kept updating the CIFS/SMB protocol.

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

          • Re:This is great news (Score:4, Insightful)

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

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

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

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

  • Not Just Linux (Score:5, Informative)

    by TheRaven64 ( 641858 ) on Saturday July 15, 2006 @10:46AM (#15724529) Journal
    FUSE has been ported to FreeBSD, and it appears that the driver also works there.

    • Re:Not Just Linux (Score:3, Insightful)

      by foniksonik ( 573572 )
      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.... ???

      • 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.
        • 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 environm
          • 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 e

        • Re:Not Just Linux (Score:4, Informative)

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

          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 (Score:4, Informative)

            by mczak ( 575986 ) on Saturday July 15, 2006 @04:52PM (#15725663)
            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 (Score:3, Informative)

              by algae ( 2196 )

              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.

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

  • No 64-bit (Score:5, Informative)

    by Bill Dimm ( 463823 ) on Saturday July 15, 2006 @10:46AM (#15724530) Homepage
    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 (Score:3, Informative)

      by waveclaw ( 43274 )
      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 /wi

  • Awesome! (Score:3, Funny)

    by The MAZZTer ( 911996 ) <(megazzt) (at) (gmail.com)> on Saturday July 15, 2006 @10:51AM (#15724536) Homepage
    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! (Score:5, Informative)

      by lord_rob the only on ( 859100 ) <shiva3003@@@gmail...com> on Saturday July 15, 2006 @11:01AM (#15724555)
      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.

      • That's a pity (Score:5, Funny)

        by Darkforge ( 28199 ) on Saturday July 15, 2006 @01:12PM (#15724982) Homepage
        ... 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 (Score:3, Interesting)

          by bfree ( 113420 )
          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.
    • 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! (Score:3, Informative)

        by Dave2 Wickham ( 600202 )
        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! (Score:4, Informative)

      by rthille ( 8526 ) <web-slashdot@ran g a t .org> on Saturday July 15, 2006 @11:05AM (#15724566) Homepage Journal
      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: (Score:2, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

    • Re:Awesome! (Score:3, Informative)

      by Bill Dimm ( 463823 )
      Have you tried the latest GParted? This article [itweek.co.uk] says a new version was released on July 9.

    • Re:Awesome! (Score:5, Informative)

      by ratboy666 ( 104074 ) <<moc.liamtoh> <ta> <legiew_derf>> on Saturday July 15, 2006 @11:09AM (#15724578) Journal
      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! (Score:3, Informative)

      by LinuxGeek ( 6139 ) *
      Help is all around [linuxmafia.com]!

    • Why? (Score:2, Informative)

      by matt me ( 850665 )
      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 s

      • Re:Why? (Score:3, Informative)

        by SirTalon42 ( 751509 )
        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.

  • Time to change my main partition... (Score:3, Funny)

    by the_humeister ( 922869 ) on Saturday July 15, 2006 @10:56AM (#15724547)
    ...from usmsdos to ntfs! Finally!
  • Can anybody explain why SourceForge's mail archive uses such freaking huge text [rave.org]? 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.

  • Cue drumroll for New! Improved! MS file system (Score:3, Insightful)

    by dpbsmith ( 263124 ) on Saturday July 15, 2006 @11:30AM (#15724663) Homepage
    This is the cue for Microsoft to roll out a new! improved! disk directory format.

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

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

    Imagine a meeting with nerds and suits present in which the nerds make the mistake of mentioning Microsoft's failure to deliver WinFS, the suits would wave their magazine and say they had, then drum their fingers, yawn, and look at their watches while the poor nerds try to explain the complex technical issues and how WinFS was supposed to therblig the frammistan while WinFS Gold merely globulorns the ferthbernder.

    • Re:Cue drumroll for New! Improved! MS file system (Score:2, Informative)

      by 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 ab
    • "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?
    • Microsoft Windows Live WinFS Enterprise 2007. That sounds more like a Microsoft naming convention.

    • 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 warnin

      • 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 [ubcd4win.com]. 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 progra

    • 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

  • Is it stable? (Score:3, Informative)

    by rsilvergun ( 571051 ) on Saturday July 15, 2006 @11:50AM (#15724719)
    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?

  • use ext3 in windows instead (Score:3, Informative)

    by radarsat1 ( 786772 ) on Saturday July 15, 2006 @01:56PM (#15725109) Homepage
    I found I prefer simply being able to access my Linux partition from Windows by installing the (unfortunately not open-source) Ext3 driver [fs-driver.org].

    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

  • Does a good job - needs more testing and funding. (Score:3, Informative)

    by wmaster ( 987425 ) on Saturday July 15, 2006 @02:15PM (#15725168) Homepage
    I have successfully installed and tested it on most recent Debian Sid/Kanotix with kernel 2.6.17 - http://kanotix.com/ [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? ;-)

  • FUSE is too slow (Score:4, Interesting)

    by caseih ( 160668 ) on Saturday July 15, 2006 @02:27PM (#15725203)
    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.

  • Now it's time to... (Score:5, Funny)

    by ivan256 ( 17499 ) on Saturday July 15, 2006 @02:30PM (#15725212)
    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.

  • Ubuntu Install (Score:4, Informative)

    by Aladrin ( 926209 ) on Saturday July 15, 2006 @04:45PM (#15725642)
    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/ [debuntu.org]

    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!

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close