Original comment: can you please include syncthing in the name of the file if you choose to go that route, as it’s not entirely clear what these extra files are for if you’re not intimately involved with the project.
Edit after split: imsodin has split this topic from a previous thread (thanks). The idea I am getting at is changing files like “.stignore” to be “.synthingignore” or something along those lines. This means that the name of the software responsible is able to be found by users who have not read all of the documentation but find themselves in possession of these files (perhaps family members who just enjoy the benefits of syncthing without actively managing it, or myself late at night when my faculties are departing me…).
I think that’s a fair point, however that’s a separate issue, given we already have .stfolder and .stignores, which should then become .syncthing-folder and .syncthing-ignores.
Keep in mind too that change is painful and there’s probably all kinds of programs and systems already expecting these files. If we were to do it right I would suggest a top level .syncthing and then files under that with visible names and extensions, so .syncthing/ignores.txt etc.
That was the second part of my initial reaction too: Agree in principle, but probably not worth changing. Or as part of a bigger change: I think there’s an issue open to move ignores to .stfolder, which would essentially be what Jakob proposes above. Any other systems depending on .stignore at folder root need adapting then, so having to adapt to both that and a name change for .stfolder seems more reasonable.
The top level thing is also the “marker name” which is already configurable on a per folder level; we could leave it as is for existing folders and just change the default. That leaves “just” moving the ignores which we can do in a backwards compatible manner (read both if they exist; in-GUI editor automatically migrates on writes).
Then if you’re managing Syncthing from some other system, you can keep writing to .stignores and have .stfolder and it’ll work. GUI-managed systems will move the ignores into .stfolder/ignores.txt. New folders will get .syncthing instead and .syncthing/ignores.txt. (And integrations are anyway better off using the API, which insulates from all of this.)
Of course all this makes the original synced ignores discussion more difficult for imsodin, because now you’re supposed to sync files inside the marker directory which is forbidden
Wouldn’t it make sense to think of this like .git in a Git repository and have the synced version outside with the option of having a non-synced file inside the marker directory with local exclusions? I guess the argument against that would be backwards compatibility, but if you’re talking about moving the ignore file in the first place…
(Edited to add: Since using synced directories can be presumed to be an uncommon thing - it’s not directly supported now - this would not add a mystery file for those not using it, which I think is the point of the above request.)
Just curious - in the case .stignore does get moved to .stfolder (or whatever the name ends up being), would this also mean that we could share the same folder multiple times, and use a custom marker name with different ignore patters inside for each of them?
