I’m unable to reproduce this with other repositories at the moment, but I’ll do my best to document this and I’m hoping to gain some insight as to why this is happening.
Running restic --cleanup-cache --cache-dir ../mycache ls a278f... --long successfully lists files in the snapshot, but only until it prints 13676635 bytes (80655 lines, plus header row). Then restic prints EOF to stderr and exits with status 1.
I can’t seem to figure out where the EOF is coming from. I’ve tried various repositories and have not been able to reproduce it between local, LAN, and remote destinations. I searched the code base and it doesn’t appear to be one that restic itself is fabricating, but comes from the Go standard lib.
However, the behavior with this repository is consistent – every time. I ran restic check and “no errors were found” (just some extra packs that could be cleaned up with prune).
It’s quite possible this has something to do with the way I’m “holding” restic, but does any of this look familiar to anyone?
(More info: it takes about 7 seconds to get to EOF with my slow network speeds, and the repository takes about 65 GB on disk.)
UPDATE: It might have something to do with using rclone serve restic as the backend. I’m not seeing any errors from rclone yet, but still investigating. The actual backend storage that rclone is connecting to seems irrelevant, since I can reproduce this behavior on multiple cloud storage providers.
UPDATE 2: I can’t even reproduce it with any other repos using rclone serve restic – so this issue is really isolated I think. Feel free to share any thoughts if you have them, but at this point I’m mostly self-documenting this for science’ sake.
): restic’s cache directory contains a truncated file, this is resolved here (but not released yet):