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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2008, 07:52 UTC
Message-ID: <7v7ihx2fdb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vmyqt657t.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

> 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.