Bisync: check file check failed

[bryan]

What is the problem you are having with rclone?

bisync with --check-access but without --resync reliably produces the error "check file check failed". After using --resync to recover, a following run without --resync again produces the same error.

Run the command 'rclone version' and share the full output of the command.

rclone v1.61.1
- os/version: arch (64 bit)
- os/kernel: 5.18.13-arch1-1 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.19.4
- go/linking: dynamic
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Dropbox

The command you were trying to run (eg rclone copy /tmp remote:tmp)

$ rclone bisync $SRC $DEST \
    --log-file $LOG_FILE \
    --max-delete 25 \
    --links \
    --check-access \
    --verbose=2

The rclone config contents with secrets removed.

[dropbox]
type = dropbox
token = {"access_token":REDACTED,"token_type":"bearer","refresh_token":REDACTED,"expiry":"2023-01-24T15:17:20.515869707-06:00"}

A log from the command with the -vv flag

2023/01/23 19:59:10 INFO  : Checking access health
2023/01/23 19:59:10 ERROR : Access test failed: Path1 count 0, Path2 count 0 - RCLONE_TEST
2023/01/23 19:59:10 ERROR : Bisync critical error: check file check failed
2023/01/23 19:59:10 ERROR : Bisync aborted. Must run --resync to recover.

[vtcifer]

Can you check the directory contents of

$HOME/.cache/rclone/bisync

[bryan]

That directory contains six files with the following extensions:

.path1.lst
.path1.lst-dry
.path1.lst-err
.path2.lst
.path2.lst-dry
.path2.lst-err

The path1 files are each 6.6M, and the path2 files are each 7.2M.

Is there something in particular I can do with those checksums?

[vtcifer]

Your file names don’t match what I would expect. In my experience they have details about the source and destination paths.

Ex:

When running

rclone bisync gdrive:rclone-lich /data --workdir /.rclone-cache --resync --verbose

My files are

-rw-r--r-- 1 pi pi 117404 Jan 24 17:30 gdrive_rclone-lich..data.path1.lst
-rw-r--r-- 1 pi pi 117404 Jan 24 17:30 gdrive_rclone-lich..data.path2.lst

What happens if you give the paths explicitly instead of as variables?

[bryan]

I provided you with the filename extensions, as I clearly specified, and omitted the private details about my source and destination paths. I specified those pseudo-variables for the same reason. I'm providing you with relevant information to help me debug the problem, while omitting private data.

Is there something in particular I can do with the checksums in those files, to address the problem I described?

[vtcifer]

I’m terrible sorry I misread your post. I guess I’m unable to assist you. Good luck.

[bryan]

Thank you, though, @vtcifer. I'm sorry if I was brash. I do appreciate your taking the time to try to help me out.

[bryan]

@ncw Any thoughts on this? I wish I had a better understanding of --check-access, as the docs don't really explain its purpose in detail. They do imply, though, that we ought to use the flag. Are the checksums mentioned above somehow the key to debugging this? Is there alternative approach I ought to try?

[ncw (Nick Craig-Wood)]

@bryan - I'm afraid we've lost our bisync developer and I don't know the code very well. If you've got the time to dig into it to figure out what is happening that would be very useful.

[bryan]

Yikes, that's awful. I'll have to make the time to investigate. Thank you for the transparency about it. I'll follow up.

[bryan]

Solved

[ncw (Nick Craig-Wood)]

Merged the doc fix - thank you