[PATCH] libb/remove_file.c: Use correct algorithm to delete directory

Laurent Bercot ska-dietlibc at skarnet.org
Mon Apr 13 11:51:44 UTC 2015


On 13/04/2015 13:38, Laurent Bercot wrote:
>   Which means that it is very possible for readdir() to keep returning
> NULL after a rewinddir() even if files have been added to the directory
> in the meantime.

  Sorry, I was wrong about that. rewinddir() actually sets the directory
in the same state as opendir(), so re-opening the directory after every
pass is unnecessary.

  The reason why the algorithm is still susceptible to a race condition is
that a file can always been added between the most recent invocation of
opendir()/rewinddir() and the next invocation of readdir(). In other words,
a concurrent process that constantly creates files will compete with the
process that unlinks them, and the results are unpredictable. Also, the
concurrent process can still create a file between a readdir() that returns
NULL (which will be interpreted as "success, the directory is empty, we can
now unlink it) and the unlink(): so unlinking the directory name can still
fail.

  I apologize for the confusion: I gave the wrong reason why this algorithm
is not better than the current busybox one. The fact remains that it is
impossible to guarantee that the unlink() of a directory will succeed, and
adding a rewinddir() loop does not add value.

-- 
  Laurent



More information about the busybox mailing list