Skip to content

Conversation

@joa-quim
Copy link
Member

@joa-quim joa-quim commented Aug 1, 2020

Fix broken situation on Windows with the lock files where files cannot be deleted if they were not closed,

@joa-quim joa-quim requested a review from PaulWessel August 1, 2020 19:24
@PaulWessel
Copy link
Member

THink this need backport, no? @seisman ?

@joa-quim joa-quim added the backport 6.1 Backport this PR to 6.1 branch label Aug 1, 2020
@seisman
Copy link
Member

seisman commented Aug 1, 2020

No bakport. The whole file lock feature is not backported.

@joa-quim
Copy link
Member Author

joa-quim commented Aug 1, 2020

Hmm, why not?

@seisman
Copy link
Member

seisman commented Aug 1, 2020

Perhaps because it's not a big issue? Of course, we can backport them (#3735, #3768, #3780, #3785) if you want.

@joa-quim joa-quim merged commit 4b8cef9 into master Aug 1, 2020
@joa-quim joa-quim deleted the fix-lock branch August 1, 2020 19:59
@github-actions
Copy link
Contributor

github-actions bot commented Aug 1, 2020

The backport to 6.1 failed:

The process 'git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-6.1 6.1
# Navigate to the new working tree
cd .worktrees/backport-6.1
# Create a new branch
git switch --create backport-3804-to-6.1
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick 4b8cef928eadefd38ae3f9a813e81cc79e94341f
# Push it to GitHub
git push --set-upstream origin backport-3804-to-6.1
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-6.1

Then, create a pull request where the base branch is 6.1 and the compare/head branch is backport-3804-to-6.1.

@seisman
Copy link
Member

seisman commented Aug 1, 2020

This PR can't be backported to 6.1 branch automatically. If you still want to backport it, we need to backport these PRs (#3735, #3768, #3780, #3785) first.

@PaulWessel
Copy link
Member

Given the number of bugs we are finding I think we need a 6.1.1 soon. So perhaps porting the lockfile stuff is a good decision.

seisman pushed a commit that referenced this pull request Aug 1, 2020
seisman added a commit that referenced this pull request Aug 1, 2020
* Let libcurl downloads be managed via lockfiles (#3735)

* Try to use filelock for downloads

We want to avoid race conditions on gmt_data_server.txt and gmt_hash_server.txt.

* Update gmt_remote.c

* Delete a failing gmt_data_server.txt file so it can be regenerated

If for whatever reason the gmt_data_server.txt ends up blank, reading will fail.  Rather than just complain about it, we now delete the file since we (a) know it is broken and (b) unless it is removed we will not attempt to refresh it for another cycle (by default 24 hours).

* Exempt URL queries from having lock files (#3768)

Since the URL of a quiery is not a good file name, we do not create an advisory lock file for such downloads.  Addresses #3765 hopefully.

* Checked wrong string for URL (#3780)

Hopefully fixes #3765.

* Forgot the other place where locking occurred (#3785)

Now both places where lockfiles are used avoids URL queries.  Closes #3765.

* Must close file before delete it (#3804)

Co-authored-by: Paul Wessel <pwessel@hawaii.edu>
Co-authored-by: Joaquim <jmfluis@gmail.com>
@joa-quim
Copy link
Member Author

joa-quim commented Aug 1, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport 6.1 Backport this PR to 6.1 branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants