Syncthing has an interesting operational issue or “feature” that should probably be removed.
I have a Mac as one of my nodes, so .DS_Store files eventually show up in each of the directories and sub-directories. I have .DS_Store ignored so that this file doesn’t propagate all over Windows or Linux.
Problem is, when I delete the directory on a Windows or Linux machine, Syncthing won’t delete it on the Mac because the .DS_Store file is not deleted and therefore the directory isn’t empty and isn’t deleted. Over time, I get lots of spare “empty” directories laying around that should be deleted. This is bad.
I never noticed this with BTSync and now specific testing confirms that when using BTSync the directory is fully deleted on the Mac when deleted on a non-Mac peer. I think this is a better feature because leaving empty directories around with .DS_Store files in them is kind of pointless because there’s nothing else in the folder.
Your reply is a bit curt and puts people on the defensive. I wasn’t asking for an explanation of why it happens or that it happens. I usually check documentation first in order to frame any questions I have.
I was trying to politely bring up the fact that it might be better to do it a different way, and I think you missed that fact. I apologize for being so oblique. I’ll be more direct.
If the endgame result as I use Syncthing through the months is that spare empty directories get littered around my directory structure, that is inappropriate.
Other sync programs delete the spare files. Old favorites like Total Commander have a click box “Remove empty directories”. So my conclusion is that there is no technical reason this can’t be done. Is there any user experience or performance reason Syncthing does what it does? If not, maybe it could change.
Maybe there could be a “hit list” of typical OS generated chaff, and if that’s all that’s left in a directory, go ahead and delete it. I do not know how BTSync decides when it’s okay to delete extra files in a Mac directory.
In fact, maybe there could be ignored files I don’t want purged. Come to think of it, I’ll go test that and see if BTSync blows away my “valuable-file.txt” just because it’s on an ignore list. That would be an equally bad design choice. Maybe I’ve just never noticed that because I don’t put “valuable-file.txt” on my ignore list.
People ~want~ to trust a new piece of software. There are certain behaviors that build trust, and design discussions to have. That’s what I was trying to open up.
If you read the ignore docs, you will see this bullet point:
A pattern beginning with a (?d) prefix enables removal of these files if they are preventing directory deletion. This prefix should be used by any OS generated files which you are happy to be removed.
So change you ignore from .DS_Store to (?d).DS_Store and deleting dirs on Windows will result in deleted dirs on MacOS if only a .DS_Store file is remaining inside it.
I am open on having discussions, but ideally on pull requests that implement the change. I don’t think there is a point of having ideological discussions of how things should work in an ideal world if nobody is planning to follow it up with the code changes, especially when we had a handful of these discussions before.
I wish I had the skill to do code changes fast. I went and downloaded Go for my computers and it doesn’t look that much different, so maybe I will try to do some programming help. For today, I have broken glow plugs on my VW car that need to be fixed…
I think we should try and educate our users to read the docs, as spoon feeding them like this just makes them lazy and they keep coming back with questions which are answered by the docs.
My answer was not useful as it doesn’t explain that the answer the person is looking for is in the docs, but putting the answer straight in a forum post does not encourage to read the docs either… Which if people did, we wouldn’t have half the support workload to start with I guess.
I guess the reason my answer was so short and blunt is because I don’t feel like having a design discussion session about things that are answered by the docs.
Others are a lot less familiar with the architecture of Syncthing and subtleties of how it works. An alternative might be a fast reference to docs with a solicitation to contribute to documentation (length or clarity) so that the next time, it’s better for everybody. …and soliciting targeted input might decrease your workload. Everybody can’t be a programmer, but maybe others could help with docs or something.
a.k.a. “Keeping or deleting .DS_Store files is configurable with Syncthing with the (?d) option in include files. If this can be explained better in the documentation, please suggest a rewrite.”
That way, I would ~still~ have to go read the docs to find out what to do, and might come up with good ideas. For now, putting .DS_Store example into the docs would be a great idea because it directly answers a problem for maybe 1/3 of your audience. I’ll experiment a bit more with the effect of putting (?d) on the Mac or putting (?d) on the Mac peers and maybe have a suggestion for the documentation.