Closed jayjlawrence closed 4 years ago
Hello JayJ, We could trap the Ctrl-C and delete the lock file, which would be much more friendly; however, canceling a run leaves the state/history of the filesystems unknown, so a --first-sync will still be required for the next run.
I don't understand the under-the-hood aspects of rclonesync as I'm just getting familiar with it.
The user-friendly improvement is welcome. As for the need for --first-sync I understand the reason. Since this is mandatory is there any interest in leaving a state for this run of "must-first-sync". This will impact the next invocation. If the next invocation is missing the first-sync option then it would fail with this error. If the user includes it the "state is removed" and the program continues. That would be appreciated by someone like me who is running the same first sync command over and over until it works right.
(I am finding numerous snags with Mac OS Catalina's more elaborate file permissions causing the sync to fail - I am growing an excludes file for this. It does suck though.)
I'm using 2.10 and you have implemented my expected behaviour. Thanks!
If the next invocation is missing the first-sync option then it would fail with this error.
This is effectively what happens. See the README under Runtime Error Handling.
v2.10 published
I find that I am having to clear the lock files after canceling a run.
The following snippet is what I found on the matter. Not being a Python programmer I am not in a position to submit a pull request. Hope this helps: