Subject: Re: [PATCH v5] lockfile.c: store absolute path

From: Michael Haggerty <[email-masked]>
Date: Wed, 05 Nov 2014 15:19:28 +0100

On 11/05/2014 03:23 AM, Scott Schmit wrote:
> On Sun, Nov 02, 2014 at 07:24:37AM +0100, Michael Haggerty wrote:
>> Locked paths can be saved in a linked list so that if something wrong
>> happens, *.lock are removed. For relative paths, this works fine if we
>> keep cwd the same, which is true 99% of time except:
>>
>> - update-index and read-tree hold the lock on $GIT_DIR/index really
>>   early, then later on may call setup_work_tree() to move cwd.
>>
>> - Suppose a lock is being held (e.g. by "git add") then somewhere
>>   down the line, somebody calls real_path (e.g. "link_alt_odb_entry"),
>>   which temporarily moves cwd away and back.
>>
>> During that time when cwd is moved (either permanently or temporarily)
>> and we decide to die(), attempts to remove relative *.lock will fail,
>> and the next operation will complain that some files are still locked.
>>
>> Avoid this case by turning relative paths to absolute before storing
>> the path in "filename" field.
> 
> This might be a little pathological, but it seems like this scheme would
> run into trouble if the entire repo is moved while the lock is held.

Correct. You shouldn't move a repository while Git operations are
running in it. That would break for many reasons, not just because of
this change to lockfile handling.

Michael

-- 
Michael Haggerty
[email-masked]