| 1 |
Hi, |
| 2 |
|
| 3 |
On Mon, 18 Sep 2006 17:13:11 +0200 |
| 4 |
alain.didierjean@××××.fr wrote: |
| 5 |
|
| 6 |
> > > For example, in Linux, you can't do 'cat .' while on FreeBSD you can. |
| 7 |
> > > Why? There is a practical reason? |
| 8 |
> > |
| 9 |
> Try vim . or, better view . |
| 10 |
|
| 11 |
It was mentioned before that applications have support for "reading |
| 12 |
directories". But application level is mostly irrelevant. The kernel |
| 13 |
doesn't support reading directories (i.e. there's no implementation for |
| 14 |
the "read" syscall for all filesystems currently in the kernel -- if I |
| 15 |
didn't miss one). Vim just does an "readdir" syscall after failing to |
| 16 |
"read", but that's application logic. I think this thread is meant to |
| 17 |
be more general. Since the kernel doesn't support "read" on |
| 18 |
directories, it is valid to claim that "linux doesn't". It can, |
| 19 |
however: Filesystems _can_ implement read() for directories. They |
| 20 |
currently just don't. |
| 21 |
|
| 22 |
Also note that according to "man 2 read" the return of an error EISDIR |
| 23 |
is conforming to SVr4, 4.3BSD, POSIX.1-2001. "The Open Group Base |
| 24 |
Specifications Issue 6" does at least say that implementations that do |
| 25 |
not support read()ing from directories will return this error (and that |
| 26 |
applications should use readdir() instead). So Linux is compliant here. |
| 27 |
It could behave differently, if filesystem designers would chose to do |
| 28 |
so. |
| 29 |
|
| 30 |
-hwh |
| 31 |
-- |
| 32 |
gentoo-user@g.o mailing list |
Archives