I use pCloud and actually really like it over Dropbox. pCloud uses what I believe is a fuse style mounting (and backend caching) in order to get access to the files. It works really well for me and I have lots of things in there.
Because I have lots of things in there I want to back it up… using restic. There is a potential pitfall… each time I run the same restic backup command I seem to have files and directories changed even though nothing has:
Files: 0 new, 5499 changed, 0 unmodified
Dirs: 0 new, 4 changed, 0 unmodified
Added to the repo: 1.666 KiB
processed 5499 files, 635.509 MiB in 0:31
Now, given that the change seems to be small (1.6kB out of a 635 MB directory) I don’t think I care that much, but when I have done it with a local filesystem the change is zero.
Now, without knowing much about how pCloud works behind the scenes I was wondering why restic might be thinking there are changes. Might it be something like the inode is changing depending on when it was cached and so more things have to be checked by restic? Though, the file size should not be changing.
I suspect that the file system provided by pCloud behaves different than a real file system. For safety reasons, restic will only skip a file as “unmodified” when several attributes are exactly the same as the last time restic saw the file, among others this includes the modification timestamp and inode. If in doubt, restic will re-read the file, and this is what you’re experiencing. What you see as “changed” is the newly added metadata for the files. You can check the timestamps and inodes by running
stat on a file, then umounting and mounting the pCloud file system again, and running the same command again while comparing the output
For fuse-based file systems, the inode is oftentimes selected at random, so it’ll be different each time restic reads the file. It’s the same for sshfs, so we already received a feature request to skip the inode check: https://github.com/restic/restic/issues/1631
So, I guess it is just a matter of adding a flag to the restic command and then passing it through to https://github.com/restic/restic/blob/b70fdf61c4efa8867cd1551ddf364ff89e9ea322/internal/archiver/archiver.go#L447 whether to do that ck or not?