Skip to content
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

backport-2.0: engine: actually unlock temp dirs on Windows #25439

Merged
merged 1 commit into from
May 14, 2018

Conversation

tbg
Copy link
Member

@tbg tbg commented May 12, 2018

Backport 1/1 commits from #25267.

/cc @cockroachdb/release


File locks are mandatory on Windows; our cleanup code was previously
assuming file system locks were advisory. Specifically, our cleanup code
was locking the temporary directory, then attempting to remove it before
releasing the lock. This worked on Unix platforms where locks are
advisory-only, but failed on Windows because the process's own lock
would prevent the cleanup! Presumably this ordering was meant to avoid a
race condition where the directory was unlocked before it was cleaned
up. It turns out this race condition doesn't matter (see the comment
within), so just unlock the directory before removing it, which works on
both Unix and Windows.

Release note (bug fix): Restarting a CockroachDB server on Windows no
longer fails due to file system locks in the store directory.

Fix #24144.
Fix #25272.

File locks are mandatory on Windows; our cleanup code was previously
assuming file system locks were advisory. Specifically, our cleanup code
was locking the temporary directory, then attempting to remove it before
releasing the lock. This worked on Unix platforms where locks are
advisory-only, but failed on Windows because the process's own lock
would prevent the cleanup! Presumably this ordering was meant to avoid a
race condition where the directory was unlocked before it was cleaned
up. It turns out this race condition doesn't matter (see the comment
within), so just unlock the directory before removing it, which works on
both Unix and Windows.

Release note (bug fix): Restarting a CockroachDB server on Windows no
longer fails due to file system locks in the store directory.
@tbg tbg requested review from bdarnell and a team May 12, 2018 00:32
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@bdarnell
Copy link
Contributor

bors r+

Merging this so it doesn't miss tomorrow's release cutoff.

@craig
Copy link
Contributor

craig bot commented May 13, 2018

Build failed

@bdarnell
Copy link
Contributor

bors r+

craig bot pushed a commit that referenced this pull request May 14, 2018
25439: backport-2.0: engine: actually unlock temp dirs on Windows r=bdarnell a=tschottdorf

Backport 1/1 commits from #25267.

/cc @cockroachdb/release

---

File locks are mandatory on Windows; our cleanup code was previously
assuming file system locks were advisory. Specifically, our cleanup code
was locking the temporary directory, then attempting to remove it before
releasing the lock. This worked on Unix platforms where locks are
advisory-only, but failed on Windows because the process's own lock
would prevent the cleanup! Presumably this ordering was meant to avoid a
race condition where the directory was unlocked before it was cleaned
up. It turns out this race condition doesn't matter (see the comment
within), so just unlock the directory before removing it, which works on
both Unix and Windows.

Release note (bug fix): Restarting a CockroachDB server on Windows no
longer fails due to file system locks in the store directory.

Fix #24144.
Fix #25272.


Co-authored-by: Nikhil Benesch <nikhil.benesch@gmail.com>
@craig
Copy link
Contributor

craig bot commented May 14, 2018

Build succeeded

@craig craig bot merged commit 676b08c into cockroachdb:release-2.0 May 14, 2018
@tbg tbg deleted the backport2.0-25267 branch May 14, 2018 02:59
@tbg
Copy link
Member Author

tbg commented May 14, 2018

First flake is

TestLogic: TestLogic/5node: TestLogic/5node-distsql (1)

@bdarnell could you get in the habit of posting a quick note about the flake when retrying? I don't want us to get in the habit of retrying flakes away without taking action.

@bdarnell
Copy link
Contributor

Filed #25465

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.

4 participants