Junio C Hamano <gitster@xxxxxxxxx> writes:
> I agree that this is a broken assumption on git's part. When we
> have this loop:
>
> while (ent = readdir()) {
> ... do something in that directory ...
> }
>
> we should expect readdir() may return new entries and cope with
> it, as "If a file is removed from or added to the directory
> after the most recent call to opendir() or rewinddir(), whether
> a subsequent call to readdir() returns an entry for that file is
> unspecified." [*1*]
Here is a result of a mini-audit.
* builtin-prune-packed.c::prune_dir() loops and unlinks (some
of) returned paths while in the loop. This should not
interfere with readdir(3). I am presuming that we can declare
readdir(3) implementation buggy if this happens:
* opendir();
* readdir() gives $P;
* unlink($P);
* readdir() later gives $P again.
Otherwise we need to lose check for return value from
unlink().
* builtin-prune.c::prune_dir() has a similar construct and the
same (non-)issue.
* dir.c::remove_dir_recursively() -- likewise.
* entry.c::remove_subtree() -- likewise. We might want to unify
this with the previous one.
A patch to "reflog-expire --all" will follow in a separate
message.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
