Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

Edgar Toernig
2001-05-24T21:17:10Z

Daniel Phillips wrote:
>
> > > Readdir fills in a directory type, so ls sees it as a directory and
> > > does the right thing. On the other hand, we know we're on a device
> > > filesystem so we will next open the name as a regular file, and
> > > find ISCHR or ISBLK: good.
> >
> > ??? The kernel may know it, but the app? Or do you really want to
> > give different stat data on stat(2) and fstat(2)? These flags are
> > currently used by archive/backup prgs. It's a hint that these files
> > are not regular files and shouldn't be opened for reading.
> > Having a 'd' would mean that they would really try to enter the
> > directory and save it's contents. Don't know what happens in this
> > case to your "special" files ;-)
>
> I guess that's much like the question 'what happens in proc?'.

And that's already bad enough. Most of the "files" in proc should
be fifos! And using proc as an excuse to introduce another set of
magic dirs? No, thanks.

> Correct me if I'm wrong, but what we learn from the proc example
> is that tarring your whole source tree starting at / is not something
> you want to do.

IMHO it would be better to fix proc instead of adding more magic. At
the moment you have to exclude /proc. You want to add /dev. And next?
Exclude all $HOME/dev (in case process name spaces get added)? Or make
fifos magic too and add all of them to the exclude list? But there's
no central place for fifos. So lets add more magic :-(

> What *won't* happen is, you won't get side effects from opening
> your serial ports (you'd have to open them without O_DIRECTORY
> to get that) so that seems like a little step forward.

As already said: depending on O_DIRECTORY breaks POSIX compliance
and that alone should kill this idea...

Over and out, ET.