> On Sun, 11 Jul 1999, Khimenko Victor wrote:
>> So do not expect working FAT any time soon... And do not expect some replace
>> for update_vm_cache as well: as Linus said it WILL be eventually implemented
>> for 2.4 if some filesystems will be still broked then but it'll not be done
>> for few weeks (or may be months)... Since most FS guru are not using FAT we,
>> mere mortals, are forced to live without FAT support for next few weeks when
>> using latest versions of 2.3.x :-/
> One of the reasons why FAT is badly b0rken is the damn 'text mode'. I.e.
> automagical translation of \r\n to \n and back.
Ahh. So we HAVE some support for albods in kernel ? Not literally but
something similar: data changed "on the fly" to support legacy programs.
It's mess :-(( So IMNSHO we DO NOT need reparse points and all this stuff
IN KERNEL. We need it in userspace (and better by user request :-)
> It is *wrong*. Not to mention the fact that it screws up on binaries and
> relies on the list of known extensions (barf) to do its magic.
> Or that renaming such files changes their visible contents. Worse yet, open,
> rename, read, close, open, read again and there you go - second read may
> return something pretty different. IMO such thing has no place in the kernel...
100% agree. I was biten by this "feature" quite a few times when accidently
forgot to turn it off and I'll be VERY happy if this crap will go away.
BTW how many ysers out there are REALLY using this crap ? I have need to
convert from/to DOS mode quite often but to me TINY, SIMPLE, yet RELIABLE
userspace program (or just perl script :-) is by far better then error-prone
magic in kernel...
P.S. I'm pretty sure that albods will be less ugly then `text mode' but still
I'm not sure if we need some automatic support for legacy applications. After
all we changed three MAJOR versions of libc for last few years (libc4, libc5,
glibc 2)... Each time ALL programs was recompiled (and in most cases patched
for compilability with recent version of glibc)... Why programs can not be just
patched to support albods (but, of course, in such case we MUST look far ahead
with changes in filesystem semantic: for at least 10-15 years or so)...
But of course complete draft of proposed changes will make discussion MUCH
more sensible. There are quite a few problems to be solved with metadata:
- mime type (/usr/share/misc/magic and extensions are ugly hacks and must be
used only as "last resort" solution when exact informations is not available)
- icons (it's REALLY usefull to use icons if you want mark files; especially
for 7-10 years old childrens -- but in such case we must deal somehow with
different icons for different users)
- compound documents
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/