Functionality Question in regards to ignoring folders...

I sync the following between two locations, four computers:

Location 1:
MacBook Pro : /Users/Shared/Ableton Live
Ubuntu Server 1: /mountpoint/mediaResources/Ableton Live

Location 2:
Ubuntu Server 2: /mountpoint/mediaResources/Ableton Live
iMac : /Users/Shared/Ableton Live

I have a server at each location and a workstation at each location. Each server acts as a hub for that location, and any workstations can sync to a specific folder on that hub, and then the hubs (servers) sync with each other.

While this is resource intensive, it’s super redundant, but also somewhat risky as I’ve learned, with bidirectional syncing.


Let’s say the following folder on each workstation is in sync:

/Users/Shared/Ableton Live/Projects/Project Name/Samples

On one workstation, I set the Project Name/Samples folder to be ignored. The result would be that all previously sync’d files would remain on each workstation and the servers, and any new changes would be ignored only by that workstation. So, if I were to delete everything in the Project Name/Samples folder on the workstation ignoring changes in that folder, no other systems would be affected.


If I “un-ignore” this folder on that workstation, will Syncthing assume that I’ve deleted those files and thus delete them from all of the other locations, or will it see that the other three systems have the files and re-populate the empty folder, restoring to the unaffected previous file set?

I did a small test and it seems it may have answered my question, but I’m still a bit unsure.

If I ignore a path before making any changes, syncthing will do nothing. If I delete a file while it is ignored, then un-ignore that folder, it seems that syncthing makes sure that the file gets put back where it was.

Is this correct?

Yes, because if you ignore it afterwards, it’s already observed, so when you un-ignore it, it observes the fact it’s no longer there.

Yet I am not sure this is the right behaviour. @calmh @imsodin, should we not just clear out the version vector when we realise the file is unignored, even if it’s gone?

Yeah. I thought that’s what we did.

There is a file that exists in the cluster, but does not exist locally, and is not ignored. It should be synced from the cluster. Any history that might have happened while it was ignored is … ignored.

I don’t see the behaviour here that is unexpected?

We do set an empty version vector, which means for deleted files we pull the global file in and for existing files that changed while ignored, it will be in conflict with the global file (unless the global file was only ever modified by use before ignoring, which is essentially

Is that true?

Seems we convert it to deleted? Or are you saying the scanner identifies it as a conflict?

Few lines below:

Sure, but I was asking where that flag is being set.

This is a file existing ignored in the db, and not existing on disk (i.e. deleted while ignored) - or do I think about the wrong scenario?
Then the scanner does never encounter it. Here case file.IsIgnored() && !ignored: applies and we fall through, detect the file is deleted, convert it to deleted and finally remove the version vector because file (from db) is ignored.

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