Re: [Btrfs-devel] btrfs and git-reflog
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 27, 2008, 08:08 UTC
- Message-ID
- <7vprvny9k4.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LFD.1.00.0801262314360.3222@www.l.google.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 18 quoted lines
> 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?Yes, I had that one in mind too, but that will cause us to miss 'b' and its only effect is to leave 'b' unpacked. If we somehow dropped 'b' and lost information that is a different story, but I do not think this failure mode would cause our current code to do so. So I do not think is a big deal even if some filesystem had a bug like that.