On Sun, 8 Feb 1998, Toby Reed wrote:
> > Unless "defragger" is one of the apps you can't live without (why?),
>
> because unlike ext2, FAT filesystems are extremely prone to fragmentation.
> And who ever said "can't live without"? I want EVERY app I currently use
> to work with the filesystem. This is not unrealistic, as UMSDOS already
> works fine.
Well, except windows 95. It fails miserably. Perhaps you hate it, but many
people find it nice. (I assume so, anyway, as it is probably the most
popular OS at the moment. In any case, it has at least a hundred times as
many people running vfat as ext2.)
> > they do work with vfat. Try it. Your DOS apps will mangle the
> > permissions and groups anyway, so you might be better off with
> ^^^^^
> If you run windows, which I do not.
>
> And my DOS apps will NOT mangle the permissions and groups with umsdos.
> They currently do not. The groups and permissions are stored seperate of
> the fat filesystem (which should be the same with long filenames, as it is
> in umsdos).
Why? I have asked people this many times, and not once have I recived an
answer. Why is it intrinsicly better that filenames shorter then 12
characters are in the directory, but those over 11 are shunted off to a
sepperate file? The problem isn't with vfat itself, the problem is with
apps that think they know how to access the fs on a byte-by-byte level.
There are only two catagories of things that should do that: the OS, and
applications whose point it is to know that. This includes fsckers and
defragmenters. It dosn't include virus scaners, word processors, disk
editors, etc. (Disk editors don't need to know about fs formating, their
users do.)
> > > separating the long filename data from the rest of it (permissions,
> > > groups, times, etc) is only going to make it harder to all get back
> > > into the same spot later on after moving files.
>
> you are thinking that I'm on a vfat filesystem, but for the last time, I'm
> NOT. Therefore the vfat filename will not be side by side with the
> --linux-.--- filename. I agree, I just got done saying that the lfns
> should be stored in one place. I personally think they should be stored in
> the same place too (the same place as all the other unix-only
> information).
I think they should be stored in the same place as all the other filenames,
the same place as the only other OS (the most popular OS in the world, I
note) looks for them.
> UVFAT makes sense ONLY if you need the long filename information outside
> of Linux. And if you're a dumb fuckhead and run Windows 95 or some stupid
> shit operating system like that, uvfat is great for you.
To play devil's advocate: umsdos make sense ONLY if you don't need the long
filename information anywhere except Linux. And if you're a dumb fuckhead
and don't understand that some people run Windows 95 or some shit operating
system like that, supporting a "standard" that isn't supported by all other
OSes that support filenames longer then eleven characters under FAT.
> But in the
> process of being great, if butt rapes everyone who hasn't converted and
> has no plans to convert to "Windows 95".
As opposed to "butt raping" everyone who has, by having two sepperate sets
of long file names.
> Windows is the last thing I would pollute my system with. That is why I
> refuse to convert to a windows propietory disk format, let alone a shitty
> one, just because a few people want to be dickheads.
Excuse me? Propietory: no, it isn't. It is well-documented (I would give
you a URL, but MS's site sucks, and their navigation applet dies under NS in
X).
Windows: vfat has nothing to do with the GUI; it just happened that it was
first implemented in NT 3.5.
Shitty one: If you were implementing vfat, how would you do it? Exactly the
same way, I'm betting. Umsdos is just as much a bad hack.
> There is no reason to drop umsdos support at this time. UVFAT is NOT (I
> repeat, NOT) a perfect replacement for UMSDOS.
No, it isn't. And umsdos isn't perfect either.
> > Consider that Linux 2.2 will be in use from about 1998 to 2001.
> > Keeping long filename baggage in the --linux-.--- file is not good.
> > The vfat filesystem also has extra timestamps, which we currently
>
> what a bunch of bullshit.
>
> It is completely non-Linux to just drop support for someone. That is what
> companies like Microsoft do every day. Many people run Linux on old 386
> and 486 class machines, because it is the only operating system that runs
> decently on them.
And it is completely non-Linux to ignore a interoperable solution when one
exists.
> DOS 6 is uncommon my ass. Maybe you just started using computers this May,
Or, you know, three augusts ago.
> but I can tell you that it is not a minority of Linux users that does not
> and will not run Windows 98. MANY people (I'd give you a number, but I
> doubt you can count that high), run DOS 6 and not Windows.
Nobody is doughting that (OK, evidently sombody is, but lets ignore him.)
What I am doughting is that it is a terrible imposition to use vfat.
> uhm, no. The umsdos filesystem is an extention that lets you use
> Unix-specific features on a FAT partition. While this was primarily
> invented to reduce the need of partitioning, it also carries the benefit
> that you can share files between DOS and Linux easily, while retaining the
> Long Filenames on the UNIX system.
Hmm... but it is of no importance that the "unix only" information is
avaible to all who could conceivably use it, which certianly includes all of
the times and complete (long) file names to windows 95 and windows NT.
> > an obsolete Linux-specific hack on officially dead Microsoft
> > filesystems that we all hate anyway.
>
> uhm....no
>
> uvfat is just as obsolete as umsdos if that is indeed the case.
> uvfat and umsdos have completely different purposes.
Hmm... I think you meen vfat and umsdos.
> VFAT is a very bad
> hack by Microsoft to allow long file names in the FAT filesystem, which
> was developed by Digital Research.
umsdos is a very bad hack by Linux guys to allow long file names in the FAT
filesystem, which was developer by Digital Research. MS isn't neccessarly
the bad guy.
> FAT is technically more reliable than
> VFAT,
Hmm? Execpt at a very high level (directory entries) level, they are
identical. Few problems occur at that high of a level in pratice.
> as in VFAT the long filenames are stored as 'bad' directory entries,
What used to be "bad". What are now specialy tagged. Unfornatly, there
weren't any reserved attribute values in fat when DR created it.
> and with weird-ass moving of files around, you can get certain files to
> get certain deleted files filenames.
And if you use umsdos on a vfat fs, you can end up with a file with not one,
not two (as is required), but three different filenames.
> And among other things, with FATs
> limit of 64 directory entries in the root directory, who knows what
> happens when you have a lot of long filenames in the root directory of a
> VFAT partition.
Me. You end up not being able to create new files in the root directory,
just as when you use the 64 directory entries with 64 files.
> VFAT is strictly Microsoft. FAT may be just as well, but it's the only
> thing that every DOS tool and program officially support.
Oh no! We could be doing somthing the Microsoft Way! And Everybody Knows
That Everything MS Does Is Bad, Don't We? That has a simple name: bigitory.
Not neccessarly everything MS has ever done is bad. Do not judge an idea by
it's source, but by it's content.
> ext and xia were obsoleted by ext2. This is not the case with uvfat. This
> is like dropping support for 2 button mice, in favor of the 3 button
> microsoft standard. "upgrade your mouse"
Interesting that most mice in the traditional UNIX world have three buttons.
Here.
Let me reformulate the problem: Umsdos and vfat have some feature overlap:
ctime and atime, and filenames longer then eleven characters. (The only
feature needed by vfat is file permissions and owners.) It would be a Good
Thing if those who use both linux and windows 95 (or NT) to be able to use
the same long filenames and times in both OSes, but still have permissions
and owners. However, vfat has some problems with some (arguably buggy)
apps.
Anything I'm missing?
-=- James Mastros
-- "Do not judge an idea by it's source, but by it's content." -=- James Mastros- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu