mirror of
https://github.com/rclone/rclone.git
synced 2024-11-22 16:34:30 +01:00
4025f42bd9
Before this change, bisync had no mechanism to gracefully cancel a sync early and exit in a clean state. Additionally, there was no way to recover on the next run -- any interruption at all would cause bisync to require a --resync, which made bisync more difficult to use as a scheduled background process. This change introduces a "Graceful Shutdown" mode and --recover flag to robustly recover from even un-graceful shutdowns. If --recover is set, in the event of a sudden interruption or other un-graceful shutdown, bisync will attempt to automatically recover on the next run, instead of requiring --resync. Bisync is able to recover robustly by keeping one "backup" listing at all times, representing the state of both paths after the last known successful sync. Bisync can then compare the current state with this snapshot to determine which changes it needs to retry. Changes that were synced after this snapshot (during the run that was later interrupted) will appear to bisync as if they are "new or changed on both sides", but in most cases this is not a problem, as bisync will simply do its usual "equality check" and learn that no action needs to be taken on these files, since they are already identical on both sides. In the rare event that a file is synced successfully during a run that later aborts, and then that same file changes AGAIN before the next run, bisync will think it is a sync conflict, and handle it accordingly. (From bisync's perspective, the file has changed on both sides since the last trusted sync, and the files on either side are not currently identical.) Therefore, --recover carries with it a slightly increased chance of having conflicts -- though in practice this is pretty rare, as the conditions required to cause it are quite specific. This risk can be reduced by using bisync's "Graceful Shutdown" mode (triggered by sending SIGINT or Ctrl+C), when you have the choice, instead of forcing a sudden termination. --recover and --resilient are similar, but distinct -- the main difference is that --resilient is about _retrying_, while --recover is about _recovering_. Most users will probably want both. --resilient allows retrying when bisync has chosen to abort itself due to safety features such as failing --check-access or detecting a filter change. --resilient does not cover external interruptions such as a user shutting down their computer in the middle of a sync -- that is what --recover is for. "Graceful Shutdown" mode is activated by sending SIGINT or pressing Ctrl+C during a run. Once triggered, bisync will use best efforts to exit cleanly before the timer runs out. If bisync is in the middle of transferring files, it will attempt to cleanly empty its queue by finishing what it has started but not taking more. If it cannot do so within 30 seconds, it will cancel the in-progress transfers at that point and then give itself a maximum of 60 seconds to wrap up, save its state for next time, and exit. With the -vP flags you will see constant status updates and a final confirmation of whether or not the graceful shutdown was successful. At any point during the "Graceful Shutdown" sequence, a second SIGINT or Ctrl+C will trigger an immediate, un-graceful exit, which will leave things in a messier state. Usually a robust recovery will still be possible if using --recover mode, otherwise you will need to do a --resync. If you plan to use Graceful Shutdown mode, it is recommended to use --resilient and --recover, and it is important to NOT use --inplace, otherwise you risk leaving partially-written files on one side, which may be confused for real files on the next run. Note also that in the event of an abrupt interruption, a lock file will be left behind to block concurrent runs. You will need to delete it before you can proceed with the next run (or wait for it to expire on its own, if using --max-lock.) |
||
---|---|---|
.. | ||
commands | ||
oracleobjectstorage | ||
_index.md | ||
alias.md | ||
amazonclouddrive.md | ||
authors.md | ||
azureblob.md | ||
azurefiles.md | ||
b2.md | ||
bisync.md | ||
box.md | ||
bugs.md | ||
cache.md | ||
changelog.md | ||
chunker.md | ||
combine.md | ||
compress.md | ||
contact.md | ||
crypt.md | ||
docker.md | ||
docs.md | ||
downloads.md | ||
drive.md | ||
dropbox.md | ||
faq.md | ||
fichier.md | ||
filefabric.md | ||
filtering.md | ||
flags.md | ||
ftp.md | ||
googlecloudstorage.md | ||
googlephotos.md | ||
gui.md | ||
hasher.md | ||
hdfs.md | ||
hidrive.md | ||
http.md | ||
imagekit.md | ||
install.md | ||
install.sh | ||
internetarchive.md | ||
jottacloud.md | ||
KEYS | ||
koofr.md | ||
licence.md | ||
linkbox.md | ||
local.md | ||
mailru.md | ||
mega.md | ||
memory.md | ||
netstorage.md | ||
onedrive.md | ||
opendrive.md | ||
oracleobjectstorage.md | ||
overview.md | ||
pcloud.md | ||
pikpak.md | ||
premiumizeme.md | ||
privacy.md | ||
protondrive.md | ||
putio.md | ||
qingstor.md | ||
quatrix.md | ||
rc.md | ||
release_signing.md | ||
remote_setup.md | ||
s3.md | ||
seafile.md | ||
sftp.md | ||
sharefile.md | ||
sia.md | ||
smb.md | ||
sponsor.md | ||
storj.md | ||
sugarsync.md | ||
swift.md | ||
tardigrade.md | ||
union.md | ||
uptobox.md | ||
webdav.md | ||
yandex.md | ||
zoho.md |