From owner-freebsd-bugs  Tue Feb 21 14:20:35 1995
Return-Path: bugs-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id OAA17426 for bugs-outgoing; Tue, 21 Feb 1995 14:20:35 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id OAA17420 for <freebsd-bugs@freefall.cdrom.com>; Tue, 21 Feb 1995 14:20:24 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA23941; Wed, 22 Feb 1995 09:14:38 +1100
Date: Wed, 22 Feb 1995 09:14:38 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199502212214.JAA23941@godzilla.zeta.org.au>
To: jmz@cabri.obs-besancon.fr, rgrimes@gndrsh.aac.dev.com
Subject: Re: ls -R does not recurse (on cdrom)
Cc: freebsd-bugs@freefall.cdrom.com
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

>> 'ls -R /cdrom' sometimes lists only the /cdrom directory and does not
>> recurse, but 'ls -lR /cdrom' works. This nevers happens after a

>For the find problem we need to pull over some patches made to 1.X find,
>try this and let me know if it works for you (I don't have a cdrom
>on a 2.x system here :-().

This doesn't explain variable behaviour.  It looks like a link counts
is wrong.  `ls -l...' has to stat everything so it doesn't have to do 
extra work to determine which files are directories.  `ls -R' apparently
uses an optimization based on the link counts of the parent directories
(a link count of 1 means that a directory can't have any subdirectories).
cd9660 and msdsofs file systems don't really have link counts but the
counts are supposed to be fudged differently for directories to make
the find hack work.

>Find /cdrom -fstype cd9660 -type f -exec file {} \;

>This may be the default file system type used by find not containing
>cd9660 (this was the problem in 1.x, only it was missing isofs).

It's mising again.  Sigh.

Bruce