Re: [Btrfs-devel] btrfs and git-reflog

Junio C Hamano [off-list ref] 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.