Trouble with: Recieve only folder + unignored stignore file with * and ! patterns

So, I’m trying to sync only a selection of my music library to my Android. The setup is not that complicated:

  1. Setup a send only folder on PC.
  2. Setup a recieve only folder on Android.
  3. Write this essentials.stignore file to the music folder on PC:
# Include this file - maybe here is the problem?
!/essentials.stignore
!/this album
!/that album
# ...
# Ignore all the rest
/*
  1. Write on Android’s .stignore:
#include essentials.stignore

In order to set it up for the first time, I had to manually copy essentials.stignore to the Android’s music folder, otherwise I got the error “can’t find included stignore file ‘essentials.stignore’”. Never mind that.

But, even after I do this, it won’t sync because it reaches this state:

Where that 1 “Locally Changed Item” is essentials.stignore.

I think the issue is that it’s not syncthing that has wrote the essentials.stignore file I started out with, but it was manually written by me. Never the less, if the files on both sides are identical, why should if fail?

Help will be appreciated.

Can you post a screenshot from the other device? Right now, the global state reads empty, so marking the file present only on the receiving side as locally changed is expected.

There is more than just content that is checked when comparing if the files are the same, they also have to have the same metadata and “history” of where they came from. You can probably revert local changes and it will be fine.

You could also copy the patterns into stignore until the file syncs by itself and then modify stignore to point at the synced file.

I tried Reverting local changes a few times, and it deleted the essentials.stignore file and brought me back to the error state where essentials.stignore isn’t found.

Somehow. after trying a few times, it started catching up, so I don’t experience the issue anymore. It’s too flaky though, so I’m currently trying to use a script to bind --mount all of the folders I wish to bind or do something else…

Thanks for your help anyway :).

As I suggested, copy the patterns into stignore, and then once the essentials file is synced, replace it with an include.

The trouble with my setup is that the same music folder is also synced as is (without ignoring any files) to another machine. My real goal is to sync different items on different clients.

The ignore system is very hard to deal with I must say, the above desired setup is reproducible I think and I think is a good use case to where a .stignore file that is not synced but is present is making me most of the trouble.

For instance, if I could only ask syncthing to read the ignore patterns out of a different file for a specific share, that would have been helpful as well - the “Essential Music” folder would have read it’s ignore settings and the “All Music” folder (which would have been pointed to the same directory on the FS) would have have not ignored any file.

It’s essentially defeating the idea of “Choose what to sync on client” vs “Choose what to scan” issue I saw coming up a lot on these forums.

You also don’t support symlinks, which is understandable, but once again it blocks other workarounds.

I hope https://github.com/syncthing/syncthing/issues/2491 will be implemeted at some point, because the design there seems excellent.

I’m currently considering running a patched, 2nd syncthing instnace that will use a different path for the ignore file (!) in order to achieve my goal. Or perhaps hardcode a specific behavior suitable for my need, in the code.

1 Like

So what I proposed is only needed for the initial setup, until after the file you are trying to include is synced, you can switch back to just including it.

I understand, sorry for not replying to your suggestion. It somehow worked for me even without this workaround, thanks again :).

Receive-only folders do in fact un-mark locally changed items if the contents are equal to the global files, regardless of history/metadata. So it should just become up-to-date if the file on the remote is the same as the local one, even if the local one was created first.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.