Reading directories (was: Re: directory copying with cp; broken?)

Ian Donaldson rcodi at yabbie.rmit.oz
Sun Oct 9 16:12:01 AEST 1988


>From article <30506 at bbn.COM>, by mesard at bbn.com (Wayne Mesard):
> Indeed.  And more generally, a consistent way of handling directories
> (i.e. directory files) needs to be established.  In SunOS 3.4:
> 
>   cp <dir> <fn>             ==>  "cp: <dir>: Is a directory (not copied).
>   head, tail, cat <dir>     ==>  {works}
>   more <dir>                ==>  "*** <dir>: directory ***"

> My preference is for cp to do the right thing (i.e, nix the -r flag) and
> for cat, head and tail (and any other file display* programs) to behave
> as more(1) does, with the addition of a new option to cat(1) to
> explicitly tell it to treat a directory as an ordinary file.

No, this is all wrong.  Directories contain OS-specific information and
should not be readable by any normal program.  There shouldn't be any
reason why anybody would need to read a directory directly at all when
there are routines for reading directories in a portable way (see directory(3)).
(mind you this has not yet trickled through to all UNIXen yet unfortunately)

The decision as to whether a program has the right to read a directory
or not should be done consistently by one part of the OS: the kernel by
returning EPERM or something.  (maybe the restriction should
be relaxed for root, I doubt if it would matter much unless you were
debugging a flakey filesystem, for which tools already exist in some
UNIXen for this purpose, and they generally don't require reading directories
other than via the raw special device).

There should NOT be gratuitous mods to almost every program in the OS that 
opens a file for reading to check if its a directory first.

Opening directories for writing is already disallowed universally (obviously), 
and reading a directory special file is already disallowed over NFS anyway 
(under SunOS 3.5 EISDIR is returned by read(2)) (why the -open- isn'
t disallowed too I can't figure out).  

So what's the problem with disallowing opening directory special files 
generally?

Ian D



More information about the Comp.unix.wizards mailing list