Skip to content

Update create-empty-bundle #1933

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 16, 2018

Conversation

dscho
Copy link
Member

@dscho dscho commented Nov 16, 2018

On the Git mailing list, the contributed v2 was countered by a better patch.

Let's update this in our branch thicket, too.

@dscho dscho requested a review from jamill November 16, 2018 15:38
dscho and others added 2 commits November 16, 2018 16:41
This reverts the patch we carried for a long time, as it did not survive
contact with the Git mailing list. In preparation for applying Jeff
King's better version, let's revert our version.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
TODO: change authorship to Peff!

bundle: dup() output descriptor closer to point-of-use

When writing a bundle to a file, the bundle code actually creates
"your.bundle.lock" using our lockfile interface. We feed that output
descriptor to a child git-pack-objects via run-command, which has the
quirk that it closes the output descriptor in the parent.

To avoid confusing the lockfile code (which still thinks the descriptor
is valid), we dup() it, and operate on the duplicate.

However, this has a confusing side effect: after the dup() but before we
call pack-objects, we have _two_ descriptors open to the lockfile. If we
call die() during that time, the lockfile code will try to clean up the
partially-written file. It knows to close() the file before unlinking,
since on some platforms (i.e., Windows) the open file would block the
deletion. But it doesn't know about the duplicate descriptor. On
Windows, triggering an error at the right part of the code will result
in the cleanup failing and the lockfile being left in the filesystem.

We can solve this by moving the dup() much closer to start_command(),
shrinking the window in which we have the second descriptor open. It's
easy to place this in such a way that no die() is possible. We could
still die due to a signal in the exact wrong moment, but we already
tolerate races there (e.g., a signal could come before we manage to put
the file on the cleanup list in the first place).

As a bonus, this shields create_bundle() itself from the duplicate-fd
trick, and we can simplify its error handling (note that the lock
rollback now happens unconditionally, but that's OK; it's a noop if we
didn't open the lock in the first place).

The included test uses an empty bundle to cause a failure at the right
spot in the code, because that's easy to trigger (the other likely
errors are write() problems like ENOSPC).  Note that it would already
pass on non-Windows systems (because they are happy to unlink an
already-open file).

Based-on-a-patch-by: Gaël Lhez <gael.lhez@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho force-pushed the update-create-empty-bundle branch from 1af9821 to 3f0700f Compare November 16, 2018 15:43
@dscho dscho added this to the v2.19.1(2) milestone Nov 16, 2018
@dscho dscho self-assigned this Nov 16, 2018
@dscho
Copy link
Member Author

dscho commented Nov 16, 2018

Thank you, @jamill!

@dscho dscho merged commit 82dacae into git-for-windows:master Nov 16, 2018
@dscho dscho deleted the update-create-empty-bundle branch November 16, 2018 15:55
@dscho dscho mentioned this pull request Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants