> All of my editors will magically know that files in one part of the
> filesystem tree are CRLF files and in another part are not?
Yes, if you really need it to be so... Or you can use LD_PRELOAD approach...
>> It can cause various problems as well if you're not careful.
> I won't doubt you if you say you've had problems. I never have.
I had.
>> Also, as stated it makes the code more difficult to maintain.
> If you're saying that the extension table shouldn't be compiled in, I can
> agree. It should be poked in via sysctl(). End of maintenance headache.
Looks like you just can not remember few words said only two dais ago.
-- cut --
a) breaking mmap() semantics.
b) breaking lseek() semantics.
c) breaking write() semantics.
d) being bloody slow, painful and kludgy.
e) making FAT support with the new page cache hard.
f) confusing the hell of unaware victims^Wusers.
g) bringing the list of magical filename extensions into the kernel.
h) belonging to userland *and* being already implemented there.
-- cut --
Looks like for you only g) is a problem and all other problems are just a
breeze. If so then can you cook up a patch ?
>> I'd like to see it go for all filesystems. Userland tools can
>> deal with it. The mount option does not remove the bloat from
>> the kernel.
> If you didn't want DOS filesystem semantics, why'd you compile it in in
> the first place? Configure it out, or don't load the module.
How DOS filesystem sematic require CRLF usage ? I use unix-style text-files in
Windows usually (internal editore of FAR handle them just fine) if at all...
If you'll convert CRLF's in WinWord file it'll just made it completely
unreadable...
-
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/