Messages in this thread | | | Date | Fri, 8 Aug 1997 09:31:50 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Msdos name alias patch for 2.1.48 |
| |
On Fri, 8 Aug 1997, Pavel Machek wrote: > > > The thing that makes me think that having the VFS layer handle > > case-insenstitivity (but nothing else) is a good idea is that it can > > potentially be useful even for things like ext2fs. Imagine having not to > > worry about case in DOSEMU or Wine, but instead doing > > > > int fd = open("/dosc/windows/windows.ini", O_NOCASE | O_RDONLY); > > _I_ think, that dosemu should be well-behaved and doing its > lower-casing auto-magically. No need dto support it in kernel.
Note that this isn't a question of lowercasing..
Suppose you have a DOS application (or wine or whatever) that you actually occasionally use for non-DOS things. I'll make this a trivial (and thus bad) example: suppose you have a DOS "list" program that you like so much more than "less" that you really want to use it all the time.
In particular, you want to do this all on non-msdos filesystems (it's not that you like MS-DOS, you just have this really cool program you want to use). So you try to use "list" on a file called "Makefile".
Oops. If dosemu convert all characters to lower case, you'll never see "Makefile" at all. But if dosemu uses "O_NOCASE", you'd actually get the right behaviour.
And note that the new dcache (if it knew about case insensitivity) would automatically handle file creations correctly too: if you tried to create a file called "makefile" but an old file called "Makefile" already existed, a case insenistive dcache would actually _find_ the old Makefile, and use that dcache entry (so you'd end up with having a file called "Makefile").
Hmm.. Timeout.
I want to clarify my thinking here a bit, so that people will understand not only what I propose, but also WHY I propose it and why I like this kind of thing so much more than the patches I've seen so far.
I have one very basic rule when it comes to "good ideas". A good idea is not an idea that solves a problem cleanly. A good idea is an idea that solves SEVERAL things at the same time. The mark of good coding is not that the program does what you want, it's that it _also_ does something that you didn't start out wanting.
For example, take the dcache. You never saw what happened in the background, but what originally happened was that Thomas sent me patches to create the dcache because he wanted to have the on-line mirroring and stuff. And trust me, I was not excited - I was very discouraging, and asked him to re-do major parts of it.
What started to convince me about the dcache was not that you could do online mirroring with it, but the fact that the introduction of the dcache allowed so much _more_ that just online mirroring. Totally unrelated stuff. It allowed a major cleanup in name lookup. It allows a fast implementation of "getcwd()". It allows the cool things you see when you do "ls -l /proc/*/fd".
Now, take something like the MS-DOS name translation thing. I do _not_ like something that hooks into the name lookup and translates the names to whatever particular format the MS-DOS low-level filesystem would like them to be in. That counts as an ad-hoc patch to cater to a filesystem that I don't particularly like.
HOWEVER. If we can make that name translation generic enough that it works for _all_ filesystems (even ext2 if you want it to), and there are no filesystem-specific hooks for it, then I already start likin git a lot more. Then it goes from being "damn ms-dos braindamage that we have to hack around" to being "the VFS layer can handle case-insensitive names".
Further, if the new feature then allows us to actually give value-added features to user space (like a O_NOCASE flag), it goes from "the VFS layer can handle case-insensitive names" to "hey cool, we can do THIS, and it's really useful for this class of applications".
Does this explain my motivation a bit? Essentially, I'm NOT really interested in how we can make the MS-DOS filesystem work.
I'm interested in seeing something that might be a good VFS feature to have anyway, and that _ALSO_ happens to make MS-DOS (and NTFS and..) happy, but more importantly I want it to make sense on some level even _without_ that.
Linus
| |