problem with readdir in Darwin-6.5?

[Jim Meyering]

FYI,

I just went to remove a directory on a local `hfs' file system from a
powerpc-apple-darwin6.5 system and was surprised to see the `rm -rf' fail.

Here's a demo:

  $ ( mkdir .k && cd .k && seq 444|xargs touch )
  $ /usr/local/bin/rm -rf .k
  /usr/local/bin/rm: cannot remove directory `.k': Directory not empty
  [Exit 1]
  fuji$ ls .k
  402  408  413  419  424  43   435  440  46  51  57  62  68  73  79  84  9   95
  403  409  414  42   425  430  436  441  47  52  58  63  69  74  8   85  90  96
  404  41   415  420  426  431  437  442  48  53  59  64  7   75  80  86  91  97
  405  410  416  421  427  432  438  443  49  54  6   65  70  76  81  87  92  98
  406  411  417  422  428  433  439  444  5   55  60  66  71  77  82  88  93  99
  407  412  418  423  429  434  44   45   50  56  61  67  72  78  83  89  94

The problem is that readdir returns NULL even though there
are remaining directory entries.  The magic number is 338:

  $ ( mkdir .k && cd .k && seq 337|xargs touch )
  $ rm -rf .k
  $ ( mkdir .k && cd .k && seq 338|xargs touch )
  $ rm -rf .k
  rm: cannot remove directory `.k': Directory not empty
  [Exit 1]
  $ find .k
  .k
  .k/99

Still using the Darwin system, the problem is reproducible
also when using a directory NFS-mounted from a NetApp.
The latter file system works just fine when mounted from a Solaris system.

Argh...  I don't want yet another configure-time
test for broken readdir (SunOS had a problem very much like
this long ago, but I obviated the work-around code when I rewrote rm).

The work-around here is probably to call rewinddir from a readdir
wrapper to be used only on deficient systems.  But then do we do the
extra rewinddir unconditionally, or add bookkeeping so we incur the
cost only if we've removed more than some minimum number of entries in
a given directory.  Yeah, `profile it'.

Nelson, do you have a way to report that problem to Apple?

In any case, I'll add a test for this.

Jim