Basically, let’s say I set the folder marker to a custom folder. Next, I add some files into it. Everything then syncs between all devices that share the folder. The custom marker is set to the same folder on all of them. This makes the default .stfolder not needed anymore, so I just delete it.
The only possible problem that came to my mind was that deleting the custom marker could possibly stop the folder on all devices, but this isn’t the case, because as soon as the marker has been deleted locally, Syncthing simply stops the folder on that device, meaning that the deletion isn’t synced to the other devices.
Is there anything else that I should be aware of when attempting such a thing? I feel that I must be missing something obvious, but nothing else comes to my mind right now .
It’s hard to reason about what would the caveats be without really knowing what it is you’re trying to achieve in the first place. Why set the custom folder marker at all (except for the sake of it)?
It’s just to store some Syncthing-related files that I want to have access everywhere without cluttering the root folder (e.g. at least several custom ignore pattern files that I use with #include, and a custom versions folder). Basically, I just want to de-clutter the root folder, and if I can use a single folder with all those files in it and also use it as the marker at the same time, why not do it?
The alternative is to remove .stfolder from hard-coded internal files, then just let it sync, and then put all those files/folders inside it. The same question remains though.
There are two separate issues here. One, if you set the folder market to some custom file or whatever, is there a danger to syncing that file? No. Two, is there danger to syncing .stfolder? Yes, because we might put folder- or device-specific things in there that should not be synced. (How would that work with a custom folder marker? I don’t know, we don’t do that currently.)
You seem determined to probe the limits of what you can and can’t do in the syncthing-owned places/namespaces. There is only one safe answer: leave them alone, because that’s what we want them for.
Use .companyname or something for your own stuff. Don’t use .stfolder, don’t use .syncthing, don’t use .syncthing.whatever.
Is this really going to happen though? It doesn’t seem feasible/safe with custom markers (or even possible at all if the marker is a file), and the overall trend seems to be to move more things into config.xml rather than create more files on the disk (e.g. when default folder settings were being implemented, the first idea was to store ignore pattern in a special .stignore file, but the later recommendation and the final solution ended up being to keep them in config.xml instead).
If I understand correctly, at least right now, it doesn’t matter if .stfolder is synced or not, as it is just an empty folder with no folder-specific information inside it. Is this correct? I’m now aware that this could potentially prove to be unsafe if things change in the future, but I control the build environment here, so unless I decide to compile and update, there won’t be any breakages.
You can of course do whatever you want on your own systems, but you’re asking for some sort of policy/opinion. My opinion is that our policy is that we “own” .syncthing* and .stfolder. Put stuff there at your own peril. .stfolder is a folder because we intended to put stuff in there, and have the expectation that we manage the files in there. My unequivocal recommendation is to not store anything in there.
I’m grateful for all the answers and explanations, of course . That’s why I created this topic in “Development” whose very description says that the category “is for topics related to hacking on syncthing” , and not in “Support” or similar. I was just curious whether there was something else that could potentially pose a problem here that I failed to see or experience in my testing.
If you’re asking from a development point of view why we’re not syncing the folder marker, I’d say it’s just because that goes counter to any envisioned usage from the beginning. Currently we don’t store anything in there, but anything we imagined we might store there (folder config, database, file checksums, ignore patterns, …) are things that should not be synced between devices.
Yeah, so I think this is a summary that I can put together.
Synchronising .stfolder won’t break things right now, but it will if Syncthing decides to store internal information there in the future.
There is no danger in synchronising a custom folder marker. Deleting it on one device won’t break synchronisation on other devices, as Syncthing will just stop the folder before pushing the deletion elsewhere.
The safest approach is to leave the marker alone and use a completely different folder, unrelated to Syncthing, to store any custom files.
One of the reasons why I’d like to have “syncthing” in the name is that I’m not the only one, who uses these folders. The other users are mostly computer-illiterate, so if they see a folder called “syncthing”, they will at least understand that they shouldn’t touch it, but if the folder is called “mycustomfoldermarker”, they will have no idea and may very well mess around with it.
One other big advantage of .stfolder that I’ve observed is that even though it hasn’t got “syncthing” in the name in full, the folder is created hidden by default (in Windows), which helps greatly in preventing the non-tech-savvy from accessing it.
.syncthing-customizations or .syncthing-$companyName and implement syncing the hidden bit and you’re golden Or maybe we already set the hidden bit on dotfiles, or could do so.
(I think I’d draw the line at calling .syncthing and .syncthing.* ours, but not necessarily anything containing “syncthing” anywhere in the name.)
Being able to hide the folder immediately at the first sync would indeed be ideal . There was a closed PR that made it possible to automatically hide dotfiles in Windows sometime last year, but the problem was that there are cases that obviously aren’t supposed to be hidden (e.g. .NET Framework). Maybe a “lightweight” version that only hides dotfiles without any spaces would be feasible? The whole concept of dotfiles doesn’t exist in the OS though, so I’m sure that there would obviously be some more false positives here.
I’d like to add that using a custom name for the folder marker is only really meant to support read-only folders where we cannot create a separate marker. And it is a per-device, per-folder setting, so different devices may expect different folder markers. Keep that in mind when talking about “the” folder marker.
It might just happen that some device deletes a path that another considers as its folder marker. Dunno what will happen then, it might be some kind of DoS “attack vector”. That’s probably one of the reasons why the default folder marker is always exempted from synchronization, and is by default the same on all involved devices.
I definitely agree with your third statement, it’s best to leave the folder marker alone. Period.
Oh yes, that statement was based on the assumption that the exact same custom marker was used on all devices that shared that folder, or at least that the deleted marker belonged to that device and not one of the others. Otherwise, the deletion would of course sync and stop the folder somewhere else.
I’ve done some more testing, and I must point out that the statement above is actually incorrect. Syncthing already stores something in .stfolder which is a file called created syncthing-encryption_password_token when the folder is Receive Encrypted. This file definitely shouldn’t be synced across different devices and/or folder types. Of course, because the folder is Receive Encrypted, Syncthing doesn’t actually push the file to other devices, yet the GUI still permanently complains about “unexpected items”, which is yet another reason why the default folder marker shouldn’t be synchronised.
I’d like to make one final statement regarding this topic.
Just do not do it. Going from this state back to normal is a nightmare. Reverting the changes and reinstalling a normal Syncthing build isn’t enough. .stfolder (possibly with its contents if any) will still be stuck in the database after doing so, e.g. Receive Only folders will be marked as “Local Additions”, and trying to revert the changes will end up removing .stfolder in the process, stopping the whole folder from syncing and requiring a manual intervention.
The only solution to get rid of the indexed .stfolder remnants seems to be wiping the whole database out (or perhaps removing and re-adding all folders one by one but this isn’t feasible when there are a lot of them), and while it may not be a huge effort on decent hardware with SSDs, I’ve got a lot of data located on slow 5200 rpm HDDs and rehashing all that takes forever.
In other words, experimenting is great but always try to think about all possible consequences in advance .
.
. That’s why I created this topic in “Development” whose very description says that the category “is for topics related to hacking on syncthing” 
, and not in “Support” or similar. I was just curious whether there was something else that could potentially pose a problem here that I failed to see or experience in my testing.
Or maybe we already set the hidden bit on dotfiles, or could do so.
.