Kopia ignores .kopiaignore symlink

I’m unsure if this is explicit/intentional behavior, so I’ll file this under maybe a bug? :slightly_smiling_face: I wasn’t able to find anything in the documentation or on the forum in any case!

Behavior

Suppose I have a .kopiaignore file located in the root of my home directory, ~/.kopiaignore.

In the service of keeping the exemplified use case simple, let’s have the contents read:

.cache

If I then do:

kopia snapshot estimate $HOME

… we verify that the ~/.cache dir was indeed excluded! In other words, this works as intended.

Now, let’s suppose instead I have my “canonical” .kopiaignore located at ~/dotfiles/kopia/.kopiaignore and I symlink that to my home directory, such that it looks like:

# ls -la ~
lrwxrwxrwx 1 user user 27 June 12 12:17 .kopiaignore -> dotfiles/kopia/.kopiaignore

If I again do:

kopia snapshot estimate $HOME

… we observe that none of the exclusions/ignores take effect!

Commentary

While obviously the above is a bit of a contrived (simple) example, it definitely caught me off-guard in terms of a real world use case just now:

Notice how, with the top snapshot, the number of files is roughly ~178K. Then, after making the above change, swapping a static file to a symlink, all of my exclusions were ignored for the subsequent snapshot (and we see a jump up of almost ~600K files and 17GB).

Use Case

I have a dotfiles repository/dir (in the Git sense) that lives within my home directory, ~/dotfiles. This directory is synced between machines that I use and/or work on regularly.

I use GNU Stow to “install” (symlink) these dotfiles onto machines.

Example:

pwd
# ~/dotfiles

ls -l
# alacritty
# git
# gnupg
# ...
# kopia
# ...

stow kopia
cd

ls -l
# .kopiaignore -> dotfiles/kopia/.kopiaignore

TL;DR: This symlinking approach allows me to keep my Kopia exclusions in-sync between machines without having to update/overwrite N different static .kopiaignore files.

For what it’s worth, I use this pattern to great success with nearly all of my “daily driver” binaries!


Which brings me to: is the behavior described above intentional?

If the answer is “no”, I’d be happy to attempt to submit a pull request and/or wait patiently for this to be addressed!

If the answer is “yes”, I’d be interested to learn more!

It’s not intentional, but Kopia indeed expects this to be a file and not symlink today. Happy to review PR to fix it.

2 Likes

Perfect, that’s exactly the answer I was looking for, thanks for the speedy response @jkowalski!

In the meantime, I’ll create a Github issue to capture this discussion and track it!