On Tue, 23 Nov 2004 cube@cubidou.net wrote:

> Because 'ls -la' opens three files, thus /dev/fd for that process
> contains those descriptors.  Those three files are actually all '.'.
>
> I don't know why ls does that, it's not my point.  But the entries
> you see for 3, 4 and 5 are really just '/dev/fd'.

Thanks a lot for this detailed explanation of the ls(1) issue.
I found it very useful.

> > localhost# ls -lR
> > total 0
> > crw-rw-rw-  1 root  wheel  5, 1 Nov 22 23:46 0
> > crw-rw-rw-  1 root  wheel  5, 1 Nov 22 23:46 1
> > crw-rw-rw-  1 root  wheel  5, 1 Nov 22 23:46 2
> > dr--r--r--  2 root  wheel   512 Nov 23 15:51 3
> > dr--r--r--  2 root  wheel   512 Nov 23 15:51 4
> > dr--r--r--  2 root  wheel   512 Nov 23 15:51 5
> > ls: 3: directory causes a cycle
> > ls: 4: directory causes a cycle
> > ls: 5: directory causes a cycle
>
> Logical, given 3, 4 and 5 are really '.'.

I see, but why are those entries directories instead of devices?
When a fdesc filesystem is not union mounted, entries in /dev/fd
are the ones I expect.

> > # ls -R
> > 0 1 2 3 4 5
>
> Well, maybe it doesn't recurse when it's '.'.

That is a very good point.

> Maybe the difference between 'ls -Rl' and 'ls -R' is worth some
> research but the rest looks perfectly fine to me.
>
> At least, I can't see any bugs in fdesc file-system in what you're
> showing.

What about the entries 3-5 as directories instead of block/character
devices???

ls -lR works perfectly if a fdesc filesystem is not mounted in /dev.

Probably not a bug... but I got not answers about this behaviour
in the last years (e.g., on usenet newsgroups).

Cheers.
Igor.