But that's exactly what happens now. Have you ever done a
grep xxxxx *
in a directory that has subdirectories? It will open the directory
(because right now we allow it to happen even without O_DIRECTORY), but
then when it reads it will get an error and will print out
grep: yyyy: Is a directory
which is obviously just not what the user meant.
So what is to say that what the user _meant_ was not to open the "default"
file for that directory?
No, I'm not 100% convinced it is a good idea. But I _am_ conviced that if
people want to test it out, they should just do so, and then when we have
a better feel for whether it makes any real sense or not can we judge
better.
For example, I would _like_ to have something like this:
PATH=~/bin:$PATH
and then in my bin directory I'd have my own binaries, some of them with
their own configuration files. For example, it could look like this:
~/bin/netscape
default -> /usr/local/bin/netscape
cache/
config
cookies/
and when somebody executes ~/bin/netscape (which is a directory with a
shorthand - the shorthand just happens to be _another_ shorthand, namely a
symlink), they actually end up _executing_ /usr/local/bin/netscape through
the shorthands, and netscape could be taught to look at argv[0] as the
location for it's own config files.
So then I could have two versions of netscape, each with its own
configuration and cache, and there would be no clashes due to both trying
to populate my home directory. More importantly, I wouldn't ever even have
to _see_ the files, except if I went out searching.
Think of it as the concept of dot-files, but taken to a higher level:
dot-files are there to hide the details, but quite frankly they don't do
all that good a job of it, and then when you occasionally want to look at
one of them and do the normal
ls -ld .??*
you end up in shock. Wouldn't it be much nicer to just do
ls ~/bin/netscape/
(note the ending slash) and magically just get all the config and other
files associated with THAT particular netscape configuration.
Again, maybe it's horrible. But It's intriguing enough that I think it's
worth at least trying.
> - This is more general: how do I know that I have to use O_DIRECTORY?
> Doing lstat(), then open() and then fstat() is not atomic.
> Following situation:
>
> - lstat() says it is a file
> - file ist moved and replaced by directory
> - I use open() without O_DIRECTORY, because I think its a file
> - now I silently open the default-file
So what's the problem? You expected to open a file, and you opened a file.
that can happen today. The fact that somebody renamed something from under
you meant that you got a different file than the one you thought you'd
get, but that is exactly the behaviour you have today.
Linus
-
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/