Add locking and traps for gtags_update.sh, and really do locking #361
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
gtags-cscope
currently has no update script trap, like ctags and cscope have, which does a partial-file cleanup on [premature] exit. if any zero-byte gtags files exist, they will be treated as a prior run by forthcoming gtags, which will be confused that the file is apparently corrupted.The attached add a trap and do cleanup in
gtags
, likectags
.Also, there was no locking in
gtags
, so this patch adds naive locking, same as the other scripts (iectags
) have already.Locking was also fixed in all the update scripts. There was a bug that existence of a lockfile was ignored. The noclobber option needs to be set in the shell, in order for 'set -e' to force an exit if the file exists already on redirect. There is a patch included to fix this. While it should be fixed, it may result in more user reports of apparent update script failure, since locking did not work before, and simultaneous attempt was never noticed.
It might be better to ignore some sources of error and exit 0 anyways so the simultaneous access is not a reported issue. But if we did this, it could hide a previous aborted attempt leaving files, and then never be able to start again. Some warning might be in order.
The changes should work both with and without
g:gutentags_cache_dir
. In this patch, the lock files are kept alongside the tags files. The other option would have been to put them in the scanned directory.Fixes #319