We absolutely NEED autonomous shadow copy folders. I don’t understand the (from a user or a dev perspective) seemingly fable-grade stubborn will to not include this feature deep under the advanced settings.
NOTHING can: cross-platform, peer to peer, online, shadow copy for redundancy, with versioning, auto resuming, no transfer corruption etc.
Let’s explore what will it take to fix this mythical roadblocking tension-bubbling pressure point.
Especially bonkers that the functionality is basically already there just not exposed.
How much money would it take? Seriously, name a price. I’ll donate big moneys for this, we’ll crowd fund it too.
Can this be hacked via scripts? There is this linux-only script workaround mentioned in a closed issue here. Not sure what it does but we need one for windows as well.
BTW the official reason is something like “Syncthing isn’t going to implement solutions that can potentially lead to automatic destruction of user files.”
Seeing as how they give you a BIG RED “REVERT LOCAL CHANGES” button that can lead to plenty of loss, I would say that an advanced setting under a “I understand what I am doing” disclaimer, or a hidden config file etc., is absolutely LESS potentially harmful than that button…
I just realized that this conversation will auto close in a month. Guess this means I will be back in a couple years to re-start this thread… (I guess once I retire I will implement my own fork, to actually be able to keep my files safely backed up unlike now because of “principles” :< )
Just for clarification, as the quote comes from myself, I’m just a contributor to the project, not really responsible for any decisions like that. The statement is simply based on what I’ve seen written multiple times either on the forum or in the GitHub issues.
If you really want to have this functionality built into Syncthing, then I can only suggest either forking the project and implementing it yourself for your own use case, or if you’re not a programmer to hire someone to do that for you.
The script posted by @rasa above is a batch script, so saving it as .bat or .cmd is the way to go. You will also need to fill in the variables in the first three lines with your Syncthing and folder information. The script also relies on curl.exe, which is only available in newer versions of Windows 10 and higher.
The script should make Syncthing revert local changes in your folder of choice. The folder is defined in the third line by its ID.
If I were you and wanted to use the script, I’d make sure to test it thoroughly with test data first, and only apply it to the actual Syncthing data once you’re 100% certain that everything works as intended. As always, making a full backup is recommended before any such experimentations.
Um, I do believe the correct approach for Syncthing to this problem, that would absolutely not at all interfere with the principle of “don’t do anything that may loose data” is the following:
Have an option to automatically treat all local changes, as file versions and put them in the .stversions folder. Versioning is -your- feature afterall.
Have a message saying smth like:
“In this mode, all local changes will be automatically treated as past versions, and moved to your versions folder. The default # of versions is 3.”
There. Done. Problem solved. Everyone happy. I will accept my Nobel, Pulitzer, Oscar, Golden Globe, and Ig Nobel now.
Yeah I hear you, I do, but tell that to the chain of: microsoft, google, ubuntu, SMB, syncthing itself, someone sneezing on a hard drive and suddenly the whole chain stops, etc. Me and all the others who kept requesting this feature, did not arrive at this robust one-directional master-slave shadowcopy via torrent feature need because we were lazy…
Whatever… I’ll try to find time to figure out, and maintain my own syncthing fork. I just want to finally protect my data in a way that actually works; because as I elaborated earlier, there is literally nothing else out there that does this as well as synchting.
It doesn’t, though. It has literally no effect except a marker in the gui. And yeah, preventing people from creating files where they’re not supposed to is mostly a solved problem in computing.
A conflict means the master can not properly overwrite the slave file. And please read & really understand the plight instead of being reductionist and oversimplifying the other person’s more complex multifaceted text.
Let me simplify it myself here: Master - Slave feature, means master overwrites the slave no matter what, (and the slaves can continue to keep their local changes if they want, through the standard .stversions procedures, thus not interfering with the “don’t loose data” mantra of syncthing).
And I was here looking for some progressive or understanding attitude, not for 2-second examples of why nothing should change. I/we have been repeatedly clear enough, and will not respond any longer unless I can see posts really thinking about where ppl like me might be coming from.
I understand what you want, which is some sort of continuous rsync --delete for backup reasons.
However that is not what syncthing does or aims to do, it’s not a backup application, so it’s simply not the right application for what you want to do. Yes, you can pretend to use it for backups, but it’s not meant for that. And we have no interest to be in that space, there are already plenty of players in that space.
Perhaps restic or some other tool meant for actual backups would be better.
even if you still insist syncing + versioning != backup, anyway it’s a transfer tool: people use synchting to synctheir backups for redundancy ----- which is why you also need one way master-slave mode so the TRANSFER can be reliable.
you keep saying “just use these other tools” – you realize everyone who came to syncthing got here after beating themselves bloody against the brick walls of everything else that exists under the open source sun, right? Yes you can come up with a simplistic handwavy scenario why you could use rsync + ftp or whatever – you can’t actually tho.
–
Haha to add to the frustrated rant – restic.net – it’s a nebulous command line tool, their website & github don’t even have the word “features” on it – doesn’t say how it works, just that it’s “backups done right” – yeah trust, nice ux mate, ppl are defs gonna pick up your product if they can’t even see what features it has. Sorry for the cynicism but you see the overarching point here…
Synchting just works. Across any ISP, router, OS, major filesystem, user skill etc. Some obscure cmd with a manual, doesn’t just work; and no doubt has roadblocks…
I still haven’t heard anyone explain why they can’t just prevent writes to a directory they want to prevent writes to, or point to any other mainstream software which has this “remove a file as soon as I save it” “feature” that is so critical.
Nobody seriously objects to using Syncthing as part of a backup strategy. I do that all the time, to a filesystem that then does snapshots. And to which no other user has write permissions, so there are never spurious edits there. Syncthing is the least of your problems if you have random people making edits to your backups, after all.
As long as the argument sounds like a version of “I’m too lazy to set up proper permissions, you should add a dangerous workaround in Syncthing instead” it’s not a serious argument.
Honestly excuse me but to my brain it looks as if you haven’t read the OP and the comment/thread I linked in the OP…
Furthermore, just because you can’t imagine x, doesn’t mean you should pull against the wave of users.
We weren’t asking to remove a file as a feature. We were saying: option to treat one peer as the master, and make sure that that master can push anything in any circumstance to the peer drive. The peers can keep their local versions as .stversions if they want.
Why? Because my grandma might open a file on the external hdd because she temporarily wanted to see smth, and then that file will be stuck in a conflict while I’m relying on it to be autonomous. Is that enough reason? Or maybe there’s some program running on that machine that goes through the files and touches them in a way that synchting thinks an edit has happened (maybe an antivirus, or smth that edits metadata, or a media server, or some permissions get changed, and synchting sees that as an edit). Or maybe some magic happens across 3 different OSes and SMB drives.
The argument sounds like “I need enough feature flexibility to make sure that an average person can set this up in whatever circumstance and it just works” - Don’t confuse that with “lazy”. Not everyone can set up a read only drive (e.g. knowledge, scenario, work laptop restrictions etc). And not everyone is a computer scientist etc.
And to be clear, I’m not angry etc that “you aren’t doing my bidding now now”, I’d be perfectly happy if you just understood the point of view of the approach.
I read both your original post and that thread now, and I’m not seeing a justification beyond someone just wanting it because they think it’s the solution.
Apart from everything else, you keep talking about this “stuck” thing. That doesn’t happen. If grandma changed the file, it changed. Fine, it’s no longer the same as it should be, and I understand you’d want that change immediately undone. Nonetheless, next time the file is changed on the other side it will get synced again. It’s not permanently stuck. (Or if it is, that’s a bug and we should fix it regardless of anything else here.)
So you want Syncthing to get into an infinite loop fighting with some other program, each time downloading the file again everytime the media server adds metadata… I would say that’s a horrible solution to the problem, with the correct solution being to simple not grant the media server write access to the files or perhaps configuring the media server to not do that.
Yeah I’m not a big believer in magic, and as along as the argument is “Syncthing should do this because there’s some magic happening on my system that I don’t understand and I can’t be bothered to figure out” … yeah, no.
I understand your point about not everyone being a computer scientist etc, but still – they can spend some time Googling a real solution to their problem, or we can provide a shitty bandaid that’s also dangerous. I’m not seeing anything here that moves the needle towards the shitty bandaid part of the spectrum. And yeah, I suspect that you understand what I’m saying and disagree, and I understand what you’re saying and disagree.
This is indeed the case (just tested) but with a caveat — a conflict file is created, which by itself still causes Syncthing to show the “Revert Local Additions” button. Maybe a good idea/recommendation to disable conflicts in Receive Only folders?
The exact same thing applies there: We can’t assume that conflict file locally has no value. You can get that behaviour already though by configuring the folder to not create conflicts, it’s just not default.
Haha to add to the frustrated rant –