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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jan 27, 2008, 07:22 UTC
Message-ID: <alpine.LFD.1.00.0801262314360.3222@www.l.google.com>
In-Reply-To: <7v7ihx2fdb.fsf@gitster.siamese.dyndns.org>

On Fri, 25 Jan 2008, Junio C Hamano wrote:

> 
> * builtin-prune-packed.c::prune_dir() loops and unlinks (some
>   of) returned paths while in the loop.  This should not
>   interfere with readdir(3).

Correct. The "loop and unlink" behaviour is common and accepted practice, and is, for example, what things like "rm -rf" tend to do.

It's only newly created files that may or may not show up in readdir() after they've been created, regardless of whether they were created under a name that was previously existed.

Show 7 quoted lines

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

Yes, but the potential problem is actually very different:

 - directory contains 'a', 'b' and 'c'

	* opendir()
	* readdir() returns 'a'
	  * unlink('a');
	* readdir() returns 'c', having skipped 'b'.

This is something that could in theory happen if a directory is indexed using the *position* of a filename in a directory. 'a' was position 1, 'b' was position 2, and 'c' was position 3. After the first readdir(), the file position was 2 (pointing at 'b'), but when we removed 'a', the other entries positions moved down, and now 'b' is at position 1, and 'c' is at position '2'. When we call readdir() the next time, it skips 'b' (because it already returned position 1!), and returns 'c'.

See? It's basically the issue of removing an entry in a linked list. And yes, we've actually had bugs like that in our in-memory tmpfs. But they were bugs, and they got fixed, and that's not how readdir() is supposed to work, exactly because it makes doing an "rm -rf" very hard.

So readdir() should basically be safe wrt 'unlink()' happening while the readdir() is running, and the only entry that can disappear is the one that is unlinekd.

So don't worry about unlink's, it's only new files being created in the same directory that can be problematic in that you don't know if readdir() will return them or not..

		Linus