X-Spam-Check-By: sourceware.org
Message-ID: <43B74F6F.5050406@tlinx.org>
Date: Sat, 31 Dec 2005 19:41:35 -0800
From: "Linda A. Walsh" <cygwin AT tlinx DOT org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: "'Cygwin List'" <cygwin AT cygwin DOT com>
Subject: simulated "leaf"s broken in root FAT32 beyond 40 entries
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

I ran into this problem using "find". 

Ran into an odd problem where directories, in my root
directory, above entry 39-40 are not being examined.  It
seems to be positionally related, but, importantly,
specifying "noleaf" seems to work around the problem.

As I understood it, Cygwin simulated the "." & ".." entries,
making it unnecessary to use "noleaf" on hard disks (?).

Here are some relevent entries from my root dir w/numbering.  Note
I'm filtering out 'noise'...
39, install/      <= last directory that works
40, FIXER.LOG
...
45, cmdcons/
46, etc/         <= will use find to show subdirs here
---output of find:
 > find / -maxdepth 2 -type d -print |egrep -i "^/install|^/etc"
/install                    #this prints out "fine"
/install/info
....
/install/etc
/install/share
/etc                        #no subdirs
---but w/noleaf...
 > find / -noleaf -maxdepth 2 -type d -print |egrep -i "^/install|^/etc"
/install
/install/info
...
/install/etc
/install/share
/etc
/etc/cron.d
/etc/stunnel
/etc/rc.d
/etc/cron.daily
...
/etc/xml
/etc/fonts
/etc/X11
/etc/bin
/etc/profile.d
/etc/ssmtp
--------

I first noticed the problem around or on Dec 13, so it _might_
have something to do with MS-updates applied around that time.  I
don't know if it was occurring before that.  My last cygwin update
had been about 5 days earlier.  I did just try updating again to
see if problem went away as mysteriously as it arrived, but it
hasn't.

The trigger for my noticing the problem was my "/tmp" dir not
being "autocleaned" (via a daily find script).  It was
a high-numbered root dir.  I found out it was a "positional" problem
by moving /tmp from a higher entry to a lower # (unsorted) entry
in the root dir.  Then "find" was able to process the
directory normally.  Weird.


I'm running SP1 (since SP2 disables auto-run scripts KB841873

Not a terrible problem if one remembers to use the workaround,
but since it is only broken "part of the time" (entries > some
fixed amount), it is a bit undesirable.  I'm guessing the #
of entries are related to whatever fits in some initial "read".
I don't know if it affects NTFS and I'm guessing it is limited
to root-level dirs or other people would have noticed it...?

-linda



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/