Slashdot Mirror
Cross-OS File System That Sucks Less?
An anonymous reader writes "I recently got an external hard disk with USB 2.0/Firewire/Firewire 800/eSATA to be used for backup and file exchange — my desktop runs Linux (with a Windows partition for games but no data worth saving), and the laptop is a MacBook Pro. So the question popped up: what kind of filesystem is best for this kind of situation? Is there a filesystem that works well under Linux, MacOS X, and Windows? Linux has HFS+ support but apparently doesn't support journaling and there's also an issue with the case-insensitivity of HFS+. Are we stuck with crummy VFAT forever or are there efforts underway to bring a modern filesystem (I'm thinking something like ZFS, BeFS, or XFS) to all platforms? Or are there other clever solutions like storing ISO images and loop-mounting those?"
NTFS-3G
Just get a USB card punch and reader. I think 029 punch code is pretty much standard.
Fight Spammers!
http://www.fs-driver.org/
I just use a external drive formatted in EXT3, and for windows files i just install the Ext3 driver.
Not really, right? Even if there was, Microsoft doesn't seem to be interested in keeping it that way. With the "advent" of Vista and whatever relational-style FS they might try to forcably upgrade us to in the future, what are the odds of the prototypical modern journaling, etc FS being shared across the two? My guess is you're stuck with ext on linux and NTFS or whatever else on Windows. Of course, you could run NTFS on Linux if you've got two big brass ones.
ext2 is supported everywhere and it's far better than fat32 or ntfs. for windows, http://www.fs-driver.org/ and for osx http://sourceforge.net/projects/ext2fsx/
There are ext2 drivers available for windows. ext2 is just ext3 without journaling. It should be a viable option.
Give me Classic Slashdot or give me death!
I'm not so sure you even read the summary. Course it's 10am on saturday so I don't blame you.
Under the influence of Post-Cyberpunk Gonzo Journalism
Since MacOSX is BSD based, I would be willing to bet that similar projects and support can be found (but, I Am Not A Mac Fanboy).
On Windows, you are pretty much stuck using either NTFS or FAT. FAT volumes can not be created in windows larger than 32GB. Although, you could create the partition using 3rd party tools to get beyond that limitation. I have had some success mounting ext3 partitions using Ext2 Installable File System For Windows or Ext2 File System Driver for Windows.
Personally, from my experience, VFAT or NTFS are about your only options.
Having been in the exact same situation I've tried all sorts of different solutions and I'd say the best current solution is NTFS, which is out of the box natively supported on both OSX and Windows (natch) and also available R/O in the default linux kernel as well as having strong R/W support now via ntfs-3g. Of course fat32 still works just fine for this application, but it's getting a little long in the tooth as far as advanced features and modern storage needs go (c'mon what is up with those weak filesize limits)!?!? And I've had some limited success with using ext2/3 on windows and linux but found that the windows kernel driver for ext2 was not very stable in my config and the userspace tools to read/write ext3 in windows was far too kludgy for my tastes; I haven't had a chance to try ext2/3 on OSX.
-*The above statement is printed entirely on recycled electrons*-
For quite some time now (10.3 Panther I think) there has been a case-sensitive variant of HFS+. The Linux kernel has supported mounting it for some time now since I contributed a patch after realizing I couldn't access my filesystem. Unfortunately, it does not support HFS+ journaling so you have to make sure OS X gets shut down properly. Also, the last time I looked, the open source HFS+ utilities like fsck did not handle case-sensitive HFS+. I looked into fixing it but it was such a god-awful mess of code I decided I didn't trust it anyway.
On Windows you should be able to use MacDrive but you may want to check with them to make sure that case-sensitive HFS+ is supported. I only say this because for instance Alsoft's DiskWarrior product didn't support case-sensitive HFS+ until very recently. Why, I don't know since case-sensitive HFS+ simply omits the case-folding step before determining b-tree position. It's all documented in TN1150.
...which is perfectly fine, because Ext3 is backwards compatible and Windows wouldn't make use of the journaling feature, anyway.
See above.
nfts-3g was the only good answer. I should have mentioned that, but the problem is a whole, not just a windows issue. Assuming that something works because OS X is posix is wrong as we are talking about data here, often un-recoverable and damned important. Stability and maturity is too important to leave up to chance.
There are two "extensions" I would like to see for vfat, that could be implemented right on top in a reasonably backwards-compatible way (just as LFNs were on top of traditional FAT fs).
.LNK files that the Windows GUI uses, but you'd want them to be supported by the OS at the filesystem layer, just like regular symlinks are on filesystems that have them; also you'd want the design of the pointer files themselves to be cleaner and more platform-agnostic.)
The easier and more important one is symbolic links. (Indeed, it ought to be possible to devise a "virtual symlink" system that would work pretty much independent of the underlying filesystem, by simply using hidden pointer files containing the paths to the target files -- similar to
The harder, but ultimately just as important, is journaling (similar to what ext3 does for ext2).
The advantage of extending FAT32 in this way should be obvious: just like with ext2/3, systems that don't support the extension can at least still access the data (although doing so may invalidate the journal). So you don't *lose* any compatibility, you only *gain* the added features. In situations where you *mostly* use the disk with a particular system (e.g., my data drive that spends basically 100% of its time mounted in FreeBSD, but is FAT32 so I can get to my data from a non-BSD system in case of an unforseen emergency), you'd get a lot of benefit from the improved features. (I'd be particularly pleased to have symlinks on my data drive, for instance.) Then you only lose the new features if you need to mount the disk under a system that doesn't support them, e.g., if some piece of hardware on my FreeBSD workstation dies and I need to get my files, I could take the drive and hook it up to just about any computer anywhere and mount it as plain old FAT32 and my files would all be there.
This still doesn't turn FAT into BeFS or ZFS or whatnot, but it would be a welcome improvement.
Cut that out, or I will ship you to Norilsk in a box.
Hi, I have exactly the same problem, One MacbookPro, One PC, and another Linux. The fact is, there isnt a portable filesystem, if you are planning on ext2/3, the mac os x driver is unstable like the hell, and will make you loose your data and crash your system, as it happens to mine. Fat and fat32 will work but with small disks only, and NTFS your linux/macos will damage it within time. I Have a 400 GB Sata external disk and currently using HFS, because its the only one that doesnt corrupt the data from time to time, and you have drivers for windows/linux. I know it isnt the best choice but if you plan to keep your data, its my advice.
ext2 is ext3 without the journaling.
There is no problem what so ever accessing an ext2/3 partition or disk from XP, it's just not journaling when writing.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
It's not just for 12cm frisbees.
Trying to use a filesystem across multiple platforms is painful. That's a clue that you're tackling the wrong problem. You don't need to share filesystems, you need to share files. Different problem with different solutions.
I set up an old PC with Linux to solve many needs. NFS and Samba provide a common pool of storage for every OS that I use. Since setting that up, I haven't ever though about shared partitions. They aren't needed.
Linux and Samba worked for me, but that's not the only solution. A NAS box might work better for you. The point is that you need shared storage, not a shared drive. Every OS supports network storage. Every OS supports backups across the network.
You read that wrong. The last paragraph of the FAQ question clearly states that EXT2IFS cannot acceess an ext3 partition that's not cleanly unmounted and will operate on an ext3 partition as if it were ext2 just like old Linux kernels without ext3 support did.
Personally I have a golden rule I always keep in mind when dealing with cross-OS file system usage: Never trust write support on foreign filesystem drivers. FAT12/16/32 is the only exception, since it's so old and primitive that anyone should have fully mastered the support of it by now. But apart from that, I'll never believe a filesystem driver to reliably write on ext2/3 outside of Linux, or HFS+ outside of OS X, or NTFS outside of Windows.
Modern filesystems are complicated beasts. One tiny error can have catastrophic results. Native filesystem drivers are the results of many years of real-life testing by millions of users. Can you really believe a third-party filesystem driver to be solid enough to write on a foreign filesystem?
Read-only support is OK because it's a magnitude easier to implement, though.
The only viable solution to cross-OS filesystem usage (without crippling yourself to FAT32) is networking.
Okay, I have to ask, have you or has anyone you know ever tried to run a Linux distro off of a NTFS system? I'm not sure why you'd want to but I'm curious as heck if it is possible.
B) Eliminate all the stupid users. This is frowned upon by society.
The reason why it's a proprietary one that is "the best cross platform one", is because the proprietary OS's refuse to support other filesystems. If windows would support Reiserfs, it'd be a much better option for cross platform than AWFUL ntfs/fat32. But unfortunately M$, for obvious reasons, refuses to do that. Meaning that open source software has to attempt to reverse engineer a crappy file system and use it, instead of having the best filesystem win out for system users of ALL platforms.
NTFS is exactly what I use for my portable hard drive that I share between Windows, Linux and Mac computers. The main reason for choosing NTFS was that I need to store big virtual machine disks where files are sometimes many gigabytes in size. In Mac OS X and Linux, I use NTFS-3G to access the drive. It works, but it's very slow when transferring many and/or large files, so I would love to have a better alternative.
Linux and Mac both have native UFS (a.k.a Fast File System) support, windows can also support UFS: http://ffsdrv.sourceforge.net/
There are ext2 drivers for Windows, but they're definitely not ready for production use. There's just not much interest in them compared to NTFS on Linux. If we want to promote ext2/3 as a Free cross platform filesystem, let's throw some support behind a good Windows ext2 driver.
Because it doesn't work. The ext2 driver for OS X is _VERY_ unstable. The last time I tried it, about five months ago, the driver caused a kernel panic. After rebooting, OS X wouldn't read the drive anymore. It was unable to seek the disk. I thought it had caused a head crash until I hooked it up to a Mac without the driver installed; that one was able to see the disk and format it. Needless to say, I removed the ext2 driver.
FAT is really the only viable option at the moment. The problem there is that you will be limited to files 2GB in size. Have a DVD image you want to access from all three platforms? Forget it. You'll either have to burn it to a DVD or use FTP, because SAMBA is limited by the same 2GB limit.
Someone else posted a response about using UDF. I'll have to look into that, but I'm not sure OS X or Windows will format a hard drive to UDF. Well, at least not with OS X's "Disk Utility" application.
The ntfs-3g website says you can boot from it, and run Linux of it, so apparently you can. Will there be any issues? Quite possibly.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
The authors of the free NTFS claim that they've found and worked around a number of bugs in Microsoft's NTFS implementation, bugs that Microsoft has later acknowledged and still later fixed.
All experience I have had, and have heard of, shows it to be robust and bug-free.
Thad
I love Mondays. On a Monday, anything is possible.
NTFS has the same issue - you can change the owner of everything - but it can take a while if you have a lot of files/directories.
Use FAT32. Yes, it sucks as a file system. But it's fine for your stated goals (backup and transfer), and it has universal compatibility. Don't discard an optimal solution just because it makes you feel uncool.
I am pretty sure you are missing some words or punctuation or something.
You do realize that for roughly the first 20 years Microsoft did not document FAT either, and Linux support comes from reverse engineering efforts?
:-)
I guess that you also don't use Samba either
4GB per file. If your backup job creates large tarballs, your hosed. At work, I was trying to backup a 20GB file to a USB external drive, and it told me the drive was out of space, even though it still had 700GB left. I had to format it NTFS for it to work.
"Be grateful for what you have. You may never know when you may lose it."
I have an external USB hard drive and recently formatted the hard drive with two different partitions. The first partition is formatted as NTFS and the second is formatted as JFS. The NTFS partition is mainly for Windows, but can also be used for transferring files between Linux and Windows. The JFS partition is only for being used by Linux. When using Linux, I can now make backup copies of stuff from my main Linux partitions onto the exteral drive's JFS partition using the rsync command. Perhaps I am being too paranoid, but I did not want Windows spyware or viruses to be able mess with what is backed up on that partition, so I deliberately chose something that Windows could not read. I use Kubuntu Linux and JFS is one of the several journaling file systems that it supports. I could have just as easily used some other Linux supported journaling file system such as EXT3 or ReiserFS, but for no special reason, I chose JFS. For the partition that Windows would use, I debated between NTFS and FAT32. I also toyed with the idea of formatting that partition as EXT2 and installing of of the several available open source drivers that would allow Windows XP to read EXT2. Linux is what I use 99% of the time and because it is my main operating system, I decided to make the JFS partition much larger and gave it 220 GB.
I have two different computers and use a KVM switch so that they can be controlled by just one keyboard, monitor and mouse. The two computers are side by side and one runs Linux and the other runs Windows XP. Most of the time I just use the Linux computer, but once in a while I turn on the Windows computer too and with the KVM switch can jump back and fort between either in about a second or two. The Windows computer is a small book sized computer that only uses 23 Watts, so I can occasionally run both at once without using much more electricity. I play around with Windows XP now and then, so that I do not totally forget to use and maintain a Windows computer.
I have the 250 GB hard drive in a NexStar GX external hard drive enclosure and it is connected to a manual 4-to-1 USB switch box. I then press the appropriate button on the manual USB Switch box to choose which computer the external hard drive is hooked to. For the first partion, I let Windows create the NTFS partion. I then used GParted running under Linux to create the JFS partition. By the way, I already had both the Ubuntu desktop package and the Kubuntu desktop package installed, so I was able to install GParted and run it under KDE, even though it is designed for Gnome.
Another alternative to all this would have been to run Samba on the Linux computer and just share a few folders at home over a wired or wireless Ethernet connection.
That was discussed couple of years ago and there were no solution found. I mean FAT32 is no solution - more of a problem. Albeit being read by most if not all OSs.
Many people in past had recommended for OS specific stuff to use ZIP archives (since they are also universally available). Additionally to preserve verbatim information from *nix/MacOS volumes you can create disk image (laying on FAT32 volume). All decent OSs allow you to mount such disk images. Formats are different so it is not portable solution to preserve not portable OS-specific information about files.
Just to reiterate FAT32 is more or less only such solution.
P.S. I have looked also into ext2 support. In MacOS 10.3.x there were no official drivers (nor such drivers materialized in 10.4). Second party solution (I found only one) crashed my MacOS during installation and didn't worked in the end. For Windows there are multiple working ext2 solutions. Though not nice, yet allowing you to extract your files from ext2 volume. Not fitting for usual everyday work - but passable.
All hope abandon ye who enter here.
I think I know the reason for this discrepancy in experiences.
Laptops.
Laptops off the bat have drives with fewer heads, and therefore are more sensitive to fragmentation. Furthermore I have seen laptops delivered with FAT file systems with 512 byte block sizes which on converting to NTFS yield cluster sizes that are smaller than optimal. I have also seen laptops delivered with 512 byte cluster NTFS.
Fragmentation is a huge problem under these circumstances, and lord help you if your MFT gets fragmented.
Pretty much the first thing I do with a new machine with Windows preinstalled is check to cluster size on C to make sure it is 4K; if not I'll use Partition Magic to resize the clusters and the partition, then create a separate partition with an 16K cluster size that I use for database files and virtual machine disks. Since those files are huge and cluster management by the OS redundant, I opt for a larger cluster size, although this does preclude using Windows filesystem compression.
This works pretty well, although I find from time to time it still helps to defrag C: on laptops. On a desktop I never bother.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.