From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 3CF821F4B4 for ; Sat, 9 Jan 2021 22:15:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726222AbhAIWMj (ORCPT ); Sat, 9 Jan 2021 17:12:39 -0500 Received: from pb-smtp1.pobox.com ([64.147.108.70]:60677 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726068AbhAIWMj (ORCPT ); Sat, 9 Jan 2021 17:12:39 -0500 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id CDD249ED3F; Sat, 9 Jan 2021 17:11:56 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=B6/OGu45KteRxWhVwawGZRBfElQ=; b=hheO1u zEsgHQFZR+1yKIS2/ow0b5Vd2c9n4CM7iERguMgrVAaPKJrpREFtFanPRkieC6eQ lGnQDx0nfWWCK+Pxn9F1Af5zmu6ujaejyEnlIf232Vrzsumv0oOSlNPgNT9uOEOj G1/vwNsgaWxm/lTBNJGT6z2/2q03ekCyV9Ex0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=SIuy9ldsPDD3s+QGZ4BR+tgqCLdflXDh qfSdyqz5U/cfnZJAksYK+6SKnFVXI3Md+sKH0wTP8ohb8TSht3tjfbGxbF2xHKGX n7vrSa2fvmHxviaSojs3sXmbPe3y0Hw9M+JiLubDtj0TUPlmZEcKviKqifQV1bIS B6SxZd/dYJI= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C5B269ED3E; Sat, 9 Jan 2021 17:11:56 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [35.196.173.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 551489ED3D; Sat, 9 Jan 2021 17:11:56 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Taylor Blau Cc: Adina Wagner , git@vger.kernel.org Subject: Re: suspected race between packing and fetch (single case study) References: Date: Sat, 09 Jan 2021 14:11:55 -0800 In-Reply-To: (Taylor Blau's message of "Fri, 8 Jan 2021 13:48:40 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: AFA3F79E-52C7-11EB-BE52-D152C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Taylor Blau writes: > Here, I think the issue is less complicated. Since you're cloning from a > local repository, the 'git clone' command calls 'clone_local()', which > in turn calls 'copy_or_link_directory()'. If the directory being copied > changes while being iterated over, the receiving end isn't guaranteed to > pick up the changes. > > Worse, if the source _removes_ a file that hasn't yet been copied, over, > then the copy will fail, which is what you're seeing here. And the source that removes a file during a repack would create a new file to keep the contents of the removed file available (if the object still matters after the repack), but because we do not retry our "cp -r" equivalent used in the clone_local(), we may not pick such a new file up. So, we probalby should document "git clone --local" that the user should expect fallout similar to what may happen when they copy a directory hierarchy with "cp -r src dst" and muck with what is in "src" while the copy is ongoing.