I'm not using this script, and I haven't looked very far into it, but based on the other scripts in this directory, I am guessing this line (which, I think, references a function that doesn't exist) was left in by accident. This commit removes it.
GitHub Pages failed to build your site.
https://github.com/evandrocoan/dotfiles/runs/1504131690
The symbolic link
/scripts/tmux-continuum/scripts/handle_tmux_automatic_start/README.md
targets a file which does not exist within your site's repository.
A TPM plugin's order bug was found and described in Issue #81.
At this point, there is no available bug-fix. Thus, a new known
issues section was added to the README file.
Fixes: #81 ("[Docs] Autosave feature depends on TPM plugins order")
Signed-off-by: Niv Nadler <nivnadler@gmail.com>
The issue and fix are described in https://github.com/tmux-plugins/tmux-continuum/issues/16 .
Without this change, tmux-continuum works only for one tmux server on the machine. In a multi-user environment (e.g. a shared server), when multiple users are running their own tmux servers, this means that tmux-continuum works only for one of the users.
This change enables tmux-continuum for one tmux server per user instead of one tmux server per machine.
* moved the locking to a separate function "acquire_lock"
* changed $[ ] to $(( )), for consistency with the rest of the file
* taking the lock only after checking all other preconditions (they are non-mutating and thread-safe)
flock is not supported on MacOS.
`mkdir` locks have a drawback: they are not cleaned up automatically. If the lock owner crashed before cleaning up the lock, the directory will stay in the filesystem and the lock will be never acquired by someone else. To avoid that, we create temporary locks (the lockdir name changes every 100 seconds). We grab two lock (N and N+1) to avoid the case where process A grabs lock N and process B grabs lock N+1 and both enter the critical section.
Fixes the case where multiple tmux sessions call auto-save at the same time, which occasionally results in multiple instances of save_all() running in parallel and causing issues like #3 and tmux-plugins/tmux-resurrect#294.
The sequence in main() is:
1. Check enough_time_since_last_run_passed
2. Save
3. Update last_save_timestamp.
The race here is:
* process A finishes step 1 and is busy with step 2. The timestamp is not updated yet.
* process B comes to step 1, sees the old timestamp and proceeds to step 2, too.
- this caused issues with the restore missing some processes and putting
others in the wrong place.
- I think this may need some work with the tmux-resurrect plugin to fix if auto
restore is to be used.
Alfred Bez