To all, who want a one-way sync from their phones to their servers and lack the “ignore deletes” feature:
If you have a unix/like server, set up the sync to directory1 (this will be the directory which is kept in sync with your phone) and create a directory2.
Then fire up a cron job, which loops over directory1 and makes a hard link for all files into directory2. Then if a file is deleted from directory1 by syncthing, it will remain in directory2.
Syncthing’s database (and the synced folder) will be in sync, yet, you’ll have the files in directory2. With Android Camera files, name collisions shouldn’t occur, but you can easily implement a conflict policy (adding timestamp or anything you like).
I gain a somewhat same behaviour as OP scenario using a ~gateway~ folder in the cluster. When I want to reclaim storage on source device(s), I just move files from the ~gateway~ folder on the target device to a folder that source device is not a member of.
You are not along. I think many of us using ST are more or less in the same shoe.
That is why I was surprised when I read Audrius said the “send only folder” on a cell phone is not a problem because new phones are not going to have a SD card in them. OK, even that is true, what if the internal memory of the phone is full? Would your suggestion be, get a new phone with more storage? With google photos, I can free my local storage. With ST, I can’t. Also Onedrive has the file on demand feature. I wonder how come they don’t have the “corrupted index” problem? Or should I just “use the other tool”?
No offense Audrius. But this is my problem nowadays. I thought computers and the programs are there to serve people. Not the other way around. When I’m told to change my way to fit or to satisfy the “system”, or I should not be needing some feature. I think something is wrong in the picture.
The fact that syncthing runs on Android is somewhat an accident. We got lucky that Go cross-compiles to Android.
Nobody is shaping syncthing to be “Android unidirectional photo backup application”. It’s not a goal of syncthing. It’s goal is bidirectional sync, make two folders look the same on both sides, which is clearly not what you want to do.
Sure, a long time ago, someone asked for it, we added some band-aid back in the early days without doing much thinking, and here we are now, with a feature we can’t remove, which behaves questionably, and people having a go at programs “not solving their problem”, when they were not designed to.
Please excuse me if I say this. I find such things a bit too philosophical.
I had read about that in other threads that this function, let’s call it “slipped into it”, was never really finished and programmed. Maybe there was a lack of desire for it, or there are other reasons, I have no idea.
It would be better and less time consuming mainly for you maintainers, to either bring a feature to a final or to announce that a feature will be removed. But then it would be removed and its not available and produce discussions for you.
Otherwise, I can agree with the previous speaker that software is geared towards needs and that features are built in or not. Let’s name a few features that, a bit exaggerated, are long-running hits in the forum, such as Ignore Delete or Selective Sync, Local Sync and others. From a philosophical point of view, all of this has to do with synchronization and you then know that both sides cannot or must not be the same.
What are your own goals is another matter, its only philosophical now.
It is not necessarily the case that we exist only to serve your needs and requirements. Software doesn’t create itself.
I don’t think we can really remove this one, except maybe by doing a Syncthing 2.0. (Hence, I guess: if/when we do a Syncthing 2.0, this feature is unlikely to survive the transition.)
And this is where we can’t serve the users need, as the application is not designed for a use case like that, so we are happy for some other application to do a better job and serve the users.
Now, sshhh behave guys. We have heard you users. We have heard you maintainers. Remember we are all humans with circumstances. My great-uncle died this year. There are limits to what each one of us is capable and we can provide to each other. One day we jump around, the other we don’t.
We have heard you:
There is demand for an already existing functionality (one way sync) that is implemented in a less than ideal way (via ignore delete). - Fair enough.
The existing functionality (ignore delete) might get dropped in future (Syncthing 2.0). - Yes and we also don’t know when that future will be. Don’t panic. Now is not the time to talk about this.
Don’t panic also, because: @calmh : “Nowadays we could probably make something smarter for the same effect.”
If somebody is willing and has the expertise or let’s say is willing to acquire the expertise to improve (in a smart way) upon one way sync will find this discussion and the corresponding github entry worthwile.
That’s all.
This is about YOU. You, the ONE who is reading this. Only you can save the world of syncthing of the threat of dropped functionality called one way sync. Only you can save the forum of syncthing being flooded with back and forth discussions. Only you are the ÜBERMENSCH. You do not get swayed by otherwordly dreams of future functionality. You are the one that starts pondering about how you could do it. Be it within the current version of Syncthing or a future version of Syncthing. You are the one that does it in a smart way, because it has to fit other functionality of syncthing. But most importantly:
You. Just. Do. It.
If you are NOT the ÜBERMENSCH: Shhh, better keep quiet. Words have been thrown and hit. Enough with the words - for now.
