simulated "leaf"s broken in root FAT32 beyond 40 entries

["Linda A. Walsh" <cygwin at tlinx dot org>]

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/