Thanks to visit codestin.com
Credit goes to github.com

Skip to content

checkout: don't try to calculate oid for directories #3931

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 1 commit into from
Oct 2, 2016

Conversation

ethomson
Copy link
Member

When trying to determine if we can safely overwrite an existing workdir item, we may need to calculate the oid for the workdir item to determine if its identical to the old side (and eligible for removal).

We previously did this regardless of the type of entry in the workdir; if it was a directory, we would open(2) it and then try to read(2). The read(2) of a directory fails on many platforms, so we would treat it as if it were unmodified and continue to perform the checkout.

On FreeBSD, you can read(2) a directory, so this pattern failed. We would calculate an oid from the data read and determine that the directory was modified and would therefore generate a checkout conflict.

This reliance on read(2) is silly (and was most likely accidentally giving us the behavior we wanted), we should be explicit about the directory test.

Fixes #3911

When trying to determine if we can safely overwrite an existing workdir
item, we may need to calculate the oid for the workdir item to determine
if its identical to the old side (and eligible for removal).

We previously did this regardless of the type of entry in the workdir;
if it was a directory, we would open(2) it and then try to read(2).
The read(2) of a directory fails on many platforms, so we would treat it
as if it were unmodified and continue to perform the checkout.

On FreeBSD, you _can_ read(2) a directory, so this pattern failed.  We
would calculate an oid from the data read and determine that the
directory was modified and would therefore generate a checkout conflict.

This reliance on read(2) is silly (and was most likely accidentally
giving us the behavior we wanted), we should be explicit about the
directory test.
@@ -212,6 +212,10 @@ static bool checkout_is_workdir_modified(
if (baseitem->size && wditem->file_size != baseitem->size)
return true;

/* if the workdir item is a directory, it cannot be a modified file */
if (S_ISDIR(wditem->mode))
return false;
Copy link
Member

@pks-t pks-t Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we consider this as modified if !S_ISDIR(baseitem->mode)? E.g. something like

if (S_ISDIR(wditem->mode))
    return !S_ISDIR(baseitem->mode);

Copy link
Member Author

@ethomson ethomson Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That can't happen - we only process files in the checkout loop, not folders. (We'll make intermediate folders if we need them.) So we'll never see a baseitem (or newitem) that is a folder.

@ethomson ethomson merged commit 9fbbb0e into master Oct 2, 2016
@ethomson ethomson deleted the ethomson/checkout_dont_calculate_oid_for_dirs branch January 13, 2017 12:28
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.

2 participants