On Mon, Oct 27, 2008 at 1:01 AM, J.C. Roberts <[EMAIL PROTECTED]> wrote: > On Sunday 26 October 2008, Paul de Weerd wrote: >> On Sun, Oct 26, 2008 at 09:51:38PM +0200, Alexey Suslikov wrote: >> | Paul de Weerd wrote: >> | > On Sun, Oct 26, 2008 at 12:01:40PM -0700, Chris Kuethe wrote: >> | > | On Sun, Oct 26, 2008 at 11:41 AM, Matthew Weigel > <[EMAIL PROTECTED]> wrote: >> | > | > Actually, (2^32)-1, or 4GB, is the max size per file >> | > | > (http://support.microsoft.com/kb/314463). I can see that >> | > | > being a problem if you're trying to run a database off of >> | > | > your thumb drive, but otherwise... can you give examples of >> | > | > files that you (or anyone you know) would like to access in >> | > | > Windows and OpenBSD that exceed this limit? >> | > | >> | > | dvd images are often >4.2G >> | > >> | > I agree with Chris here .. the only time I've wanted to transport >> | > large files between windows and basically !windows (macosx, linux >> | > and *bsd) they were ISO's of either regular CD's (works) or DVD's >> | > (doesn't fit in fat32). >> | > >> | > Happened to me on a couple of occassions that I wanted to do this >> | > and had to resort to network transfers (non-optimal in those >> | > circumstances). >> | >> | Come on guys. >> | >> | I believe OpenBSD can do read/write on ext2. No? >> | >> | And there is the http://www.fs-driver.org/ - also free >> | and do read/write on ext2 for Windows. >> >> True, but it's an external add-on that you may not always be able to >> install on the windows machine (which in my case usually isn't mine). >> OpenBSD, FreeBSD, NetBSD, Linux, Mac OSX .. they all have 'native' >> support for FAT32. >> >> Granted, I don't see an easy solution for this issue (because in >> essence it would mean that all others need proper ntfs support). >> > > Hi Paul, > > It seems you and others are missing the obvious; If Microsoft actually > wanted other operating system vendors to read and write NTFS, they > would have provided the specifications. > > Trying to build and maintain compatibility with a vendor which > specifically doesn't want you to build or maintain compatibility is an > exercise in futility. There is no easy solution because Microsoft does > not want an easy solution to exist. If anyone does create an easy > solution, Microsoft will undoubtedly, once again, change things so they > remain incompatible. --Oh and don't forget MS FAT/FAT32 is patent > encumbered so the only reason why you still have "native support" for > it is because Microsoft has not pushed the issue in the courts or > taking the time to write a new incompatible version of FAT32. > > If you consider an ever changing, undocumented, closed source file > system to be a problem, the best thing you can do is migrate to using > something else. > > OpenBSD does provide read access to NTFS for the sake of faster > migration, but even this is fairly unnecessary since one could transfer > the data over a network connection. There's no reason to bloat the > OpenBSD kernel with a feature designed as a fast solution to a > temporary problem, namely migration. > > The answer is not fighting for NTFS support, instead, the answer is > migrating away from NTFS. If someone absolutely insists on running > something intentionally incompatible, the only viable answer is to > leave them out in the cold until they change their mind.
Exactly. More faster people forget about NTFS/FAT32, more faster interoperability problem will be solved. People wanted NTFS just forgot about the fact what they want not NTFS itself but interoperability between a number of systems. Alexey
