You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background: I'm trying to set up rclonesync.py for an HPC environment, meaning that good I/O practices can't be guaranteed. Users who don't know how to avoid hammering files, or who of necessity use programs that are not designed for HPC/don't handle I/O properly, could be writing to files many times per second at sync time.
When a file is being constantly written to, though, running rclonesync.py fails hard enough that it must be rerun with --first-sync before it can be run normally again. I can understand why it would fail--a file that's getting hammered isn't a good candidate for syncing--but is there anything preventing the failure from being graceful, i.e. allowing the next try to succeed without requiring --first-sync? I know that bidirectional syncing is a hard problem, so I may be missing something obvious that means one simply has to be careful not to engage in foolishness like for i in {1..99999}; do echo $i >> myfile; done while syncing. However, if there is a way to more gracefully handle such cases, it would mean a more robust rclonesync.py.
The following case illustrates my point. In essence, I run rclonesync.py while a local file is being written to 100 times per second, and cause a critical error abort:
$ rclone mkdir dropbox:rclonesync_testdir
$ mkdir rclonesync_testdir
$ cd rclonesync_testdir/
$ echo"file 1"> file1.txt
$ rclone copy file1.txt dropbox:rclonesync_testdir
$ rclonesync.py . dropbox:rclonesync_testdir --first-sync # works2019-05-03 16:22:24,816: ***** BiDirectional Sync for Cloud Services using rclone *****2019-05-03 16:22:24,845: Lock file created: </tmp/rclonesync_LOCK_._dropbox__rclonesync_testdir_>2019-05-03 16:22:24,846: Synching Path1 <./> with Path2 <dropbox:/rclonesync_testdir/>2019-05-03 16:22:24,846: Command line: <Namespace(Path1='.', Path2='dropbox:rclonesync_testdir', check_access=False, check_filename='RCLONE_TEST', config=None, dry_run=False, filters_file=None, first_sync=True, force=False, max_deletes=50, no_datetime_log=False, rc_verbose=None, rclone='rclone', rclone_args=None, remove_empty_directories=False, verbose=False, workdir='/fslhome/micgre93/.rclonesyncwd')>2019-05-03 16:22:24,846: >>>>> --first-sync copying any unique Path2 files to Path12019-05-03 16:22:26,280: >>>>> Path1 Checking for Diffs2019-05-03 16:22:26,280: >>>>> Path2 Checking for Diffs2019-05-03 16:22:26,280: >>>>> No changes on Path2 - Skipping ahead2019-05-03 16:22:26,280: >>>>> Synching Path1 to Path22019-05-03 16:22:26,876: >>>>> Refreshing Path1 and Path2 lsl files2019-05-03 16:22:27,494: Lock file removed: </tmp/rclonesync_LOCK_._dropbox__rclonesync_testdir_>2019-05-03 16:22:27,494: >>>>> Successful run. All done.
$
$
$ foriin {1..1000};do sleep 0.01;echo$i>> file2.txt;done& rclonesync.py . dropbox:rclonesync_testdir[1] 843452019-05-03 16:23:31,004: ***** BiDirectional Sync for Cloud Services using rclone *****2019-05-03 16:23:31,037: Synching Path1 <./> with Path2 <dropbox:/rclonesync_testdir/>2019-05-03 16:23:32,648: 1 file change(s) on Path1: 1 new, 0 newer, 0 older, 0 deleted2019/05/03 16:23:33 ERROR : file2.txt: Failed to copy: upload failed: Post https://content.dropboxapi.com/2/files/upload: can't copy - source file is being updated (size changed from 288 to 380)2019/05/03 16:23:33 ERROR : Dropbox root 'rclonesync_testdir': not deleting files as there were IO errors2019/05/03 16:23:33 ERROR : Dropbox root 'rclonesync_testdir': not deleting directories as there were IO errors2019/05/03 16:23:33 ERROR : Attempt 1/3 failed with 2 errors and: upload failed: Post https://content.dropboxapi.com/2/files/upload: can't copy - source file is being updated (size changed from 288 to 380)...[truncated for brevity]...2019/05/03 16:23:36 Failed to sync: upload failed: Post https://content.dropboxapi.com/2/files/upload: can't copy - source file is being updated (size changed from 1288 to 1364)2019-05-03 16:23:36,513: ERROR rclone sync failed. (Line 473) - ./2019-05-03 16:23:36,513: ***** Critical Error Abort - Must run --first-sync to recover. See README.md *****
Is this fixable? If not, do you have any suggestions on how to handle cases like this? Since adding --first-sync does make the issue at least superficially go away (at least after the file hammering is finished), what would be the implications of using --first-sync every time rclonesync.py is run?
The text was updated successfully, but these errors were encountered:
Interesting problem. I'll think about if its safe to simply skip a file that fails the rclone transfer. For the individual file copy from path2 to path1 I know which file failed, but for the final rclone sync from path1 to path2 it seems unsafe. Hum... Also see issue #8.
Note that there is a risk of data loss with --first-sync. Newer versions of files on Path2 will be lost. Be careful.
I'm out of town for a bit. Perhaps next week I'll get back to this.
Regards
Background: I'm trying to set up
rclonesync.py
for an HPC environment, meaning that good I/O practices can't be guaranteed. Users who don't know how to avoid hammering files, or who of necessity use programs that are not designed for HPC/don't handle I/O properly, could be writing to files many times per second at sync time.When a file is being constantly written to, though, running
rclonesync.py
fails hard enough that it must be rerun with--first-sync
before it can be run normally again. I can understand why it would fail--a file that's getting hammered isn't a good candidate for syncing--but is there anything preventing the failure from being graceful, i.e. allowing the next try to succeed without requiring--first-sync
? I know that bidirectional syncing is a hard problem, so I may be missing something obvious that means one simply has to be careful not to engage in foolishness likefor i in {1..99999}; do echo $i >> myfile; done
while syncing. However, if there is a way to more gracefully handle such cases, it would mean a more robustrclonesync.py
.The following case illustrates my point. In essence, I run rclonesync.py while a local file is being written to 100 times per second, and cause a critical error abort:
Is this fixable? If not, do you have any suggestions on how to handle cases like this? Since adding
--first-sync
does make the issue at least superficially go away (at least after the file hammering is finished), what would be the implications of using--first-sync
every timerclonesync.py
is run?The text was updated successfully, but these errors were encountered: