Windows Alternatives to NTFS? 140
Maidjeurtam asks: "I'm a multi-OS user. Although Linux is what I use the most these days (I run it on my primary P4 box and on my iBook), I also run Mac OS X and a Windows XP on other machines. Of course, those boxes are networked, but sometimes, I just prefer to plug one machine's hard disk into another. I often work with big DV files (> 4GiB) and it looks like I have no other choice than having a different filesystem on each of my boxes. Granted, Linux can read NTFS (Macs can too) and even write to NTFS partitions thanks to tools like Captive, but I don't like the idea of running Windows code on my Linux box. In fact, I don't want my data stored on a proprietary, closed filesystem. I've googled a bit and it seems there's no modern (free-as-in-speech) filesystem I can install on Windows. I'd love to have ReiserFS running on my XP box, for example. Am I condemned to stay with NTFS, or do you guys know of a Windows-compatible, open filesystem that I can use?"
FAT (Score:1)
File size (Score:4, Insightful)
Last I checked, you couldn't have files over 4 gb in size on a FAT partition.
Re:File size (Score:4, Informative)
Last I checked, you couldn't have files over 4 gb in size on a FAT partition.
Maybe not, but most modern DV tools have options to break files into manageable-sized chunks, usually 1 or 2 Gb.
Re:File size (Score:1)
As for >4GB files, that's not my problem.
Re:File size (Score:1)
http://www.microsoft.com/resources/documen
MS Windows can mount FAT 32 partitions larger than 32 GB, but will not create partitions larger than 32GB.
Re:File size (Score:3, Interesting)
You *CAN* and *DO* create FAT32 partitions larger than 32Gb in various revisions of Windows. The largest one I have created, using Microsoft's own Windows Installer, was 200Gb. However, there are many revisions that have an added 'feature' which removes this ability. The Win2k OEM CD that came with my laptop, for instance, refuses. Yet my friend's Win2k CD happily creates FAT32 partitions as bi
Re:File size (Score:2)
The friendly chap that runs a small computer shop in town said we will just try it, no risk. After the disk was put in he used an XP-PRO disk to format it to a single 60 Gb partition.
Regretfully as NTFS, so once at home I used the Toshiba OEM W98 disk to reformat the drive to FAT32, still 60 Gb an
Re:File size (Score:2)
Re:File size (Score:1)
err!
jak
Re:File size (Score:1)
Re:File size (Score:1)
Re:File size (Score:2, Informative)
I believe FAT32's cluster limit is closer to 28 bit than a full 32 bits. The maximum FAT32 partition is 8TB, not 128TB as a full 32-bit FAT would imply.
Follow up (Score:2)
However, using Linux, I have created, and STILL USE a 62 GB FAT32 partition. I use it both in Linux and Windows with no problems. Windows can mount a much larger FAT filesystem than it will create.
This is not conjecture
Re:File size (Score:1, Informative)
And on top of that there is a ~32GB partition size limit.
Re:File size (Score:5, Informative)
That's an artificial limit imposed by Windows, to get people to switch to NTFS. Pick up a copy of PartitionMagic, it'll create those large FAT32 partitions just fine.
Re:File size (Score:1)
Re:File size (Score:2, Informative)
Win98 DOES have the previously mentioned file limit, as well as a limit in partition size (at least when formatted by Windows).
On the other hand, if you look at a program like Adobe Premiere, the file sizes are rarely as big as you think th
Re:FAT (Score:2)
I've found that Linux (at least 2.4.something) will have problems using a fat32 filesystem over 128 GB in size. Windows will work with it fine, but Linux will work mostly but writing to one file will eventually cause another file to get truncated to zero bytes ... nasty.
I never really tracked down exactly what was going on, but it was easily reproducible on at least two different boxes just by creating a fat32 partition over 128 GB, using both mkdosfs and Partition Magic
ISO9660 (Score:5, Informative)
What we did for file systems was standardize on ISO9660 throughout, though we are considering a move to UFS so we have support for larger files. Windows supports it, though you have to hack the registry to get write access enabled, and we ended up writing a custom "disk format" tool to actually get disks initialised because, needless to say, W2K doesn't actually allow you to format disks as ISO9660 by default.
Well recommended. There are some neat features of ISO9660, like the VAX/VMS style "versions" for instance. Unfortunately, bog standard ISO9660 has crappy 32.3 style filenames (and for maximum compatability we're encouraged to just do 8.3), so it's not a perfect solution (another reason we want to switch to UFS.)
Definitely recommended though. It's a little slow, but everything will read it.
Re:ISO9660 (Score:4, Informative)
Re:ISO9660 (Score:2)
Fat sucks (Score:1)
Re:Fat sucks (Score:1, Informative)
It's limited though. Limited file sizes, limited partition sizes, limited file attributes, limited numbers of files in directories, no compression or anything like that. No journaling, etc. Those are reasons why people don't use it... performance is not one of them.
Re:Fat sucks (Score:1)
All file systems
Re:Fat sucks (Score:1)
Re:Fat sucks (Score:3, Informative)
s/FAT32/bubble sort/
I'm afraid that I can't agree with you.
"Simplicity" doesn't mean much from a computer science standpoint (Does little code need to run? Few disk accesses required?)
One reason why FAT32 is slow is that its space allocation data structure looks something like a linked list, whereas traditional *IX filesystems look like a tree. To seek to a random poin
Re:Fat sucks (Score:1)
Re:Fat sucks (Score:2)
Seriously, don't listen to Microsoft. They want you to upgrade for their own reasons, not necessarily because it's the best thing for you. NTFS has some serious advantages over FAT32, security, namely, but FAT32 was never intended to be a secured FS. In the case of the poster, it may be exactly what he wants.
--trb
Re:Fat sucks (Score:2)
Both partitions were formatted using WinXP defaults, FAT32 at 16k segment size, and NTFS at a 1K segment size. NTFS has 86% free space, FAT32 has 38% free space. Both are defragmented and the results were duplicated on multiple hard disk drives, two at
Re:Fat sucks (Score:2)
NTFS is not just more reliable, but it also has security on the filesystem. Remember with FAT32, all you can do is file sharing permissions. If someone logs in locally they have full control over the entire file system. NTFS by default is the same way, but can be locked down.
Re:Fat sucks (Score:2)
You may want to turn off "last access" timestamping. It's a registry setting [windowsnetworking.com], and at least on NT 4.0 and Windows 2000, it is enabled by default; the equivalent option in Linux is the "noatime" mount option.
Also, NTFS is sensitive to fragmentation. Pe
Re:Fat sucks (Score:3, Informative)
First, it sounds like you have two different partitions on the same hard drive. That's a no-no for benchmarks. The first partition (the one at the outer edge of the disk) will always have much better performance than the second partition (the one closer to the middle). The disk spins at a constant RPM, but the outer cylinders have more tracks on them, so you get more data per revolution.
Second, the 1k default "segment" size for NTFS (cluster, methinks) only kicks in for fairly
Re:Fat is compatible (Score:2)
I'm aware of the outer sectors reading slowly -- I see it painfully obviously where on a clean disk a "dd" (I have linux on the sys too, dual boot) will start at rate X and almos
Re:Fat sucks (Score:2)
Just that difference in cluster size will make a massive difference, depending on what the benchmark does.
Re:Fat sucks (Score:2)
-l
ext2 (Score:4, Informative)
Re:ext2 (Score:1, Informative)
http://uranus.it.swin.edu.au/~jn/linux/explore2fs
Re:ext2 (Score:1)
http://sys.xiloo.com/
Reiserfs under windows (Score:3, Informative)
Reiserfs under windows [sssup.it]
May work? (Score:5, Informative)
Its read-only, command-line access!
You type commands like this:
extdump \\.\PHYSICALDRIVE1 -o 68b3cb000
If you want to read a file.
Sam
Re:May work? (Score:2, Funny)
Re:May work? (Score:2)
That is what we all prefer is it not?
Much safer than clicking on some fuzzily-defined button!
Why doesn't somebody write one? (Score:3, Interesting)
A while ago I downloaded the Windows DDK from Microsoft for something, but I didn't end up using it, uninstalled it and now I can't find the download. Unfortunately, it doesn't seem avail. for free from Microsoft's site anymore either (Microsoft WHDC DDK page [microsoft.com]). I have work to do, but this page seems like it might be of some help: OSROnline.com [osronline.com]... maybe.
Anyways, the idea still stands, why aren't there win32 branches of open source file system drivers? Of course, I know squat about writing drivers, especially filesystem drivers, so there may be a damn good reason why not. But figured I'd throw it out anywho.
Re:Why doesn't somebody write one? (Score:3, Insightful)
Re:Why doesn't somebody write one? (Score:1, Troll)
Oh, that's easy. It would improve Windows. We can't have open source code used to improve Windows. Why? Because that is just religiously wrong.
Really you have something there, but on
Re:Why doesn't somebody write one? (Score:3, Informative)
You can get a GPLed reimplementation of ntifs.h here [acc.umu.se], it apparently works but i've never tried it myself. There's several example drivers there, and links to some attempts at Ext2 filesystem drivers for NT.
Re:Why doesn't somebody write one? (Score:2)
Re:Why doesn't somebody write one? (Score:2)
Also, writing Windows device drivers is -- how do I put this -- not very much *fun*. It's *hard*, extremely labor-intensive, there is not equivalent to Linux's "merge into the mainstream kernel" which means that people avoid breaking your code with their own feature additions, since Microsoft isn't going to take your code.
Finally, I can't think of all that many problems with NTFS. The main probl
Re:Why doesn't somebody write one? (Score:2, Interesting)
I've been using NTFS write support for the past several versions.
I don't know if people assume NTFS doesn't work on linux because distro's don't generally include it in their kernel builds or because the write support was horrid and corrupted filesystems once upon a time.
Re:Why doesn't somebody write one? (Score:2)
Re:Why doesn't somebody write one? (Score:2)
But apparently someone wants this hushed up because I've been modded troll in 3 places for comments which mention that *shrugs*.
Re:Why doesn't somebody write one? (Score:2)
In 2.6.5:
To mount an NTFS 1.2/3.x (Windows NT4/2000/XP/2003) volume, use the file
system type 'ntfs'. The driver currently supports read-only mode (with no
fault-tolerance, encryption or journalling) and very limited, but safe, write
support
Also see the linux-ntfs website.
Re:Why doesn't somebody write one? (Score:2)
In REALITY I've been using full blown NTFS write support for 2yrs without a single corruption.
Now that is without doing anything particularly fancy, I wouldn't go trying to run your system on it. I generally treat it as FAT32 in terms of what I expect to work or even try.
No symlinks, no attempting to do anything with permissions, and of course you wouldn't touch any NT system or operating files or folde
Re:Why doesn't somebody write one? (Score:5, Informative)
1. The officially-sanctioned IFS developer kit is separate from the DDK and costs ~$1000 last time I checked. That's steep for someone who's hacking on open source in their spare time. Even if you get it, AIUI, it's very underdocumented and you'll take quite a few lumps before producing anything useful. And the license looks to my (untrained) eye as if it specifically prohibits distributing source code for the file system drivers you develop.
2. Windows filesystem drivers are hard. Developing and debugging is hairy and time consuming, and it's a good bit more work than writing an equivalent UNIX-like filesystem driver. For example, Windows expects the filesystem to handle globbing (wildcards), which is normally handled by the shell on UNIX.
3. Kernel drivers require specialized knowledge to develop and maintain. The people who have acquired this knowledge about the popular Free/Open Source drivers are, naturally, UNIX experts. They are unlikely to have the same knowledge about developing Windows kernel drivers and very unlikely to enjoy working with Windows enough to gain this knowledge in their spare time, at their own expense.
4. People who understand windows kernel driver (especially IFS) development don't, as a group, do open source. I have a few friends who do this, and they have actually mentioned that they view open source as a threat to their livelihoods and hope it goes away. One of them used the phrase "commie bullshit". I'm not joking.
5. The free kits for Windows filesystem development appear primarily targeted at academic use, and are not robust enough (or maybe simply not well-enough understood) to produce a production-quality filesystem. Some development would most likely need to go into one of the kits before it could be used to port a non-trivial filesystem with all of the expected features.
This all adds up to a serious lack of any "somebody" who can and is willing to write one, especially for free.
That said, there are a couple of free ext2/3 implementations available for various versions of windows. I've tested them, and the one that was read/write didn't seem good enough for use with any important data.
One company that I know of has developed a commercial implementation of ext2/3fs for Windows. It's not free, but for <$30 it may be inexpensive enough to be interesting [partition-manager.com].
Waaaaaah (Score:1, Insightful)
And this is why you will die very lonely.
Seriously though, what does it matter? You want files over 4 gig in Windows? You pretty much have to use NTFS. Deal with it.
Re:Waaaaaah (Score:2)
1) Built into Windows, supported by Linux/etc.
2) Much better than FAT(32); in stability, large file size handling, security, etc.
3) Difficult (if not impossible?) to use any other file system type in Windows, other than FAT32/NTFS. See reason #1.
If you ask a stupid question, expect a stupid answer.
Good question (Score:2)
Currently ext2 might be an alternative. There are two open source drivers, both quite buggy. There is also a commercial solution, which produces strange things. It worked for a while, then writing under (2k) makes double double sized - so it becomes full pretty quickly, unless you switch back and forth to do an fsck (which will repair, I mean correct the size with
Don't use Windows (Score:4, Insightful)
Hmm, then maybe don't use Windows?! Seriously, why complain about the file system in particular when the entire OS is closed source. It's one thing to say "I only use OSS," but it's another to say "I don't mind closed source software, except for on this one part - there it's bad."
Windows is optimized for NTFS now, and NTFS is good. If you don't want propritary stuff, don't use Windows, period.
Re:Don't use Windows (Score:2)
If you're post was to mean "stop bitching and use NTFS" then I agree with you. This necessity for open source gets annoying sometimes when it comes to something like a file system. What actual limitations is he going to incure using NTFS that he wouldn't incure while using an open fs in windows using add-ons to support it? I think this guy's just being diffi
Re:Don't use Windows (Score:3, Informative)
As far as speed... well I haven't benched it, but it's not particularly dog slow... I copy files of whatever size and don't get annoyed.
Read support has been stable for ages, although NTFS support is not generally compiled into any main distro kernel by default.
As for write support, at first it ate filesystems and completely corrupted them. Then they made a util to fix them... maybe. Then it got better. Then it got much better (in the meantime everyone has been ranting a
Don't use Windows . . . Natively (Score:2)
This is what I do.
Re:Don't use Windows . . . Natively (Score:2)
exploring ext2/3 from windows (Score:2, Informative)
Explore ex2fs [swin.edu.au]
Reiser? (Score:5, Insightful)
Reiser is not really appropriate here, because you want a filesystem for "large" files. Reiser's strength and efficiency is in large numbers of small files.
Re:Reiser? (Score:2)
Really, ext2, ext3, reiser, jfs, and xfs are all pretty much general-purpose filesystems. Yes, they all have particular areas in which they perform somewhat better than the others, but it's really not worth ripping your hair out over. I'd be more likely to choose something based on the few features that differentiate them (ext2 is forwards-compatible with ext3, or that reiser can optionally give up some speed to store small files more compactly).
No (Score:5, Informative)
Windows supports FAT32 and ISO9660 out of the box. FAT32 does not provide enough error recovery to be recommendable. People using ISO9660 as a hard-drive file system are crazy masochists -- enough said. There are seemingly abandoned ports of Ext2 and ReiserFS out there. None of them are in any sense stable for production use.
Why aren't there more file systems available on Windows? The first clue is that Windows is not an open-source platform; open-source hackers tend to live on open-source platforms. The people who work on kernel-level development under Windows are likely to be pursuing commercial software from the outset.
Furthermore, Windows kernel development is something of a black art; it is hard enough that you need to have some vested interest in the platform in order to stay; you would want to live and breathe Windows kernel APIs. (APIs, incidentally, that don't seem constructed for use by humans; for example, due to the limited size of the kernel addressing space, there are several different "kinds" of memory you must carefully allocate and manage yourself. Add to this the awkwardness involved in debugging this stuff, the poor kernel-level development tools offered by Microsoft, the limited documentation, the fact that much third-party information is non-gratis, and of course that the kernel sources themselves are closed, and you have one painful hobby.) In short, you would want to become a kernel specialist.
These painfully-accrued skills are worth their weight in gold, and used to leverage careers as highly-paid consultants [winternals.com] or highly-paid trainers [azius.com], or both [osr.com]. And some, of course, are driver writers for hardware companies.
There's a further reason: Linux file system drivers, in my experience, are designed to be, well, Linux file system drivers. Witness the amount of effort taken by IBM and SGI to port their proprietary journaling file systems to Linux -- and this was from one Unix-like kernel to another. Windows' internal file-system driver API is completely different from Linux'. Porting one file system not only requires a lot of knowledge about the different kernel APIs, but also about the file system itself, because most likely the file-system code is not cleanly separated from the kernel-specific code; you can't just sit down and write an adapter layer. (This is actually mostly speculation, but based on casual perusal of some existing driver code.)
There will be viable, open-source file systems on Windows the day somebody takes the time and effort do implement (and maintain) one. As for myself, I bought the book [amazon.com] and started; I gave up not because it was technically challenging, but because it was no fun, and there were more interesting knowledge out there that I wanted to store in my brain.
Re:No (Score:2)
Re:No (Score:2)
Re:No (Score:2)
I wish O'Reilly would put it up on Safari!
Probably not (Score:4, Interesting)
Fortunately for you, MS does have a filesystem-abstraction mechanism known as SMB, which several projects (most notably the SAMBA project) have implemented. These systems communicate with Windows via SMB, presenting information to the OS with parameters it understands. By proxy, then, the MS OS doesn't care a whit about what back end FS it's writing to - as far as it's concerned, it's just like any other MS OS via the network.
So probably the best solution is to have a network-mounted drive connected via a high-speed link (gigabit ethernet, etc.) on a linux box running SMB. If you do it right, you should hopefully have enough bandwidth to do your video and have it hosted wherever you like.
Good luck!
Re:Probably not (Score:2)
Does anyone know how or if it is even possible to hook up two computers (one Win2kserver, on linux (debian preferred)) with firewire800 via pci cards and have SMB shares on linux _and_ windows?
Does anyone have any idea about the throughput of such solutions?
Re:Probably not (Score:5, Informative)
cdfs.sys for CDFS
fastfat.sys for FAT12/16/32
mrxdav.sys for WebDav (access files over http using normal file ops)
mrxsmb.sys for SMB
msfs.sys for mailslots (the mailslot filesystem)
mup.sys- the multiple UNC provider driver; to handle \\computername\share\path
npfs.sys for named pipes (the named pipe filesystem)
ntfs.sys for NTFS
udfs.sys for UDFS
Windows certainly supports third-party file system drivers. The problem is that the Microsoft IFS [microsoft.com] (installable filesystem) kit costs $899. There is a free/open alternative here [acc.umu.se].
However, in practice, there are no alternatives to MS filesystems. Your suggestion of a SMB server over a fast connection is a good one.
Re:Probably not (Score:2)
hey you got it! (Score:3, Interesting)
You might have just hit it.
The issue with wanting everthing OSS on windows is that it makes migration easier. Almost every company has 1 or 2 apps that have to be on windows...so the key is
Re:Probably not (Score:1)
This is my pet project... (Score:1)
On the side, I've been trying to round up information on what it takes to do this, but it sure has been a pain.
I'm not really sure why Microsoft it so tight-lipped about the IfsKit and the DDK, but my best guess is that they don't want the kind of support issues that would come with too many different kinds of file systems. I suppose they're thinking that if they make the
Re:This is my pet project... (Score:2)
Might be a performance hit, IDK, but (Score:1)
Granted, I realize then you're copying stuff back and forth. But it seems to be the least buggy, most reliable solution.
Re:Might be a performance hit, IDK, but (Score:2)
Re:Might be a performance hit, IDK, but (Score:1)
Re:Might be a performance hit, IDK, but (Score:2)
I can see lots of reasons for this. from ISPs that distribute windo
Do what I do - NFS (Score:2, Informative)
I can rip DV footage to it with no lost frames and no problems. I also do a lot of audio recording, and can record at least 12 simultaneous tracks to it.
I can access it from any computer, it's never down,
UDF (Score:2)
Random Article [earthweb.com] link.
using paragon ext2fs might be a solution (Score:2)
Maybe I'm the only one who noticed... (Score:5, Interesting)
For good reason I'd say, I've been using NTFS write support for the past several revisions without a single hiccup.
First I was cautious and ginger in my handling of NTFS writes, and then more bold. Now I don't consider corruption anymore than I would with windows. I guess that comes from hundreds if not thousands of writes without a single issue *shrugs*.
In any case, if the kernel maintainers think it's safe to take off the experimental tag, and I've used it without any problems. Maybe it'll go well for you too.
NTFS write used to be horrid, and required external cleanup utils just to use. That's long long gone, if you've been afraid to touch it because of being burned in the past, seriously, it's time to try again.
Re:Maybe I'm the only one who noticed... (Score:4, Informative)
"CONFIG_NTFS_RW:
This enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (
It is perfectly safe to say N here."
Re:Maybe I'm the only one who noticed... (Score:2)
However I stand by what I said, in the two years I've been using NTFS write support routinely I haven't seen one hint of this corruption nonsense.
NFS? (Score:2, Informative)
Gigabit ethernet card are cheap these days and you can get yourself a nice SATA raid that will be able to handle your huge DV files.
Seb
NFS (microsoft services for unix) (Score:2)
You can stream to that over a standard network with peak rates that approach line speed (100 mbit) and I get sustained 90 mbit rates every day (just don't overload those disks, as they are ide disks, not meant for constant use)
Re:s/Slashdot/Google "AskSlashdot" (Score:1)
my $forum = "AskSlashdot";
$forum =~ s/Slashdot/Google/i;
print $forum;
exit;
Re:s/Slashdot/Google "AskSlashdot" (Score:2)
Re:s/Slashdot/Google "AskSlashdot" (Score:2)
Re:s/Slashdot/Google "AskSlashdot" (Score:2)
"Microsoft DFS" is nothing but a redirector that creates the illusion of a single filesystem tree from a set of regular old SMB servers.
Re:s/Slashdot/Google "AskSlashdot" (Score:2)
Re:s/Slashdot/Google "AskSlashdot" (Score:2)
Why can't someone write a virus that prevents Windows from creating Recycle Bin directories on any partition it gets near?
Re:s/Slashdot/Google "AskSlashdot" (Score:3, Informative)
Re:s/Slashdot/Google "AskSlashdot" (Score:1)
Re:Give me a break... (Score:1)
Re:Give me a break... (Score:4, Interesting)
2) The poster, as you so unusefully point out, is aware of read access under Mac OS X and Linux, and is perfectly aware that he doesn't have an _access_ problem per se. He does, however, have an _access_ problem in that he can only write from one side. If he needs to write from the other he needs to move the files off box.
3) Apparently you're reading things the rest of us aren't. The poster is not complaining about things just because they're proprietary. What he is asking is if there is a way to do what he wants to do. You fail miserably to even address his issue in your brief rant.
To the moderator or called you 'insightful'. Stop smoking crack, it makes you feed the trolls.
-T
Suck my Karma Bonus.
Re:Give me a break... (Score:2)
The part which is no longer marked experimental isn't full write support however. A couple people corrected me on that and I double checked and their correct.
However you can still turn on NTFS write support and NTFS write support has worked great for me since I'd say about midway through the 2.4 kernel series. No special trick, just turn it on and use it.
A few disclaimers, i'm not even sure I've used it since using a 2.6 kernel, I'm not sure I haven