Ignore Delete

Feature
1

I’m missing the information about Ignore Delete in the overview of the folders at the main screen. I suggest to add it to the Folder Type item of the folder (e.g. “Folder Type: Receive Only, Ignore Deletes”). Also putting this option into the Advanced tab of the Edit Folder dialog would be convenient.

Is there a good reason why Ignore Delete is hidden in the Advanced settings?

Related question: Does one device know how is the shared folder configured at another device? In particular, does one device know that the other device has the shared folder configured as Receive Only and Ignore Deletes? What folder metadata are exchanged between devices?

4 Likes
2

Ignore Delete is a feature we want to deprecate, so we’re not adding it anywhere.

I believe Devices don’t know the configuration of remote folders.

3

I use Ignore Delete on many of my folders. Why do you want to deprecate it? Are you planning to replace it with something else/better :-)?

1 Like
4

It’s widely used (-ish…) so we can’t just remove it, no. But it’s ill considered and has annoying side effects. Nowadays we could probably make something smarter for the same effect.

5

The way it’s implememented is effectively a checkbox saying “please corrupt my index unrecoverably”. Once you enabled it, disabling it will not suddenly do the right thing, and you’ll be forever out of sync.

It’s possible to reimplement it correctly, but I doubt if it’s on anyones plans. Deprecating it would be done in the next major release, which in it self is not clear when it’s happening, given how much bending over backwards we did not to break backwards compatability.

Ideally, don’t use it, as we want to get rid of it.

2 Likes
6

@AudriusButkevicius I would understand if you want to replace it with something better. E.g. other sync programs distinguish between bi-directional sync, uni-directional mirror and uni-directional “backup” (mirror with ignoring deletes), which is IMO more convenient than how ST does it. But if you get rid of the third (uni-directional “backup”) option, ST will become almost unusable for me.

For instance, the following scenario I mentioned here in the forum many times:

I use ST for backuping photos from our mobile phones to NAS. I configured ST synchronization as uni-directional “backup”. In ST language it means that the “Camera” folder is set as Send Only at the phone side, and Receive Only + Ignore Deletes at the NAS side. This setup allow me to delete photos from the mobile phone (in order to free the limited storage) without fearing that they will be deleted from NAS as well. How would you do the same without Ignore Delete?

2 Likes
7

As I said we’re not just going to yank it so there’s no need to argue against that.

8

Uff, @AudriusButkevicius frightened me.

9

So back to my original problem. Is this change going to happen any time soon? If not, could it be possible to show the status of Ignore Delete in the folder overview, till then? I understand that you do not want to move the checkbox itself from the Advanced settings.

1 Like
10

That said, with your send only + receive only setup you already have two “filters” on the sync direction. The only thing ignore-deletes does here is prevent the “revert” button from showing up on the receive only side.

Until ignore-deletes is somehow improved to not be an ugly hack I’m also opposed to making it more visible.

2 Likes
11

I’d still argue that people using syncthing for uni-directional backup are using the wrong tool.

We don’t officially support that, and the only reason it somewhat works is because of that hack flag that you managed to find buried deep where we don’t want people to see it.

I think it’s best if you find an application that supports this scenario, instead of living in fear that we we’ll remove a hack.

I don’t think we’ll be adding/exposing anything related to ignore deletes in it’s current from, because as it stands it’s 3 lines of code that does terrible things, so adding more convenience for a terrible thing is definatley a nono.

12

FTR;

(keeping in mind no +1 please)

13

That doesn’t seem true to me. Without Ignore Delete file/folder removals woud be propagated as well.

I spent quite a long time searching and testing various sync apps that would be cross-platform (work on Win, Android and Synology NAS) and support various sync modes. The fact is that there’s no better app than ST, despite of that ST is not perfect. It offers some unique features that no other app has. In particular, I appreciate that I do not need to use username/password authentication in order to backup devices. Of course, ST is not a backup program.

I do not understand why ST should not support one-directional sync. I understand that bi-directional sync may be sufficient for you, but others may find use of other scenarios as well - including me.

2 Likes
14

Sorry, you’re of course right about ignore deletes, I was thinking the deletes happened on the other side.

Syncthing is explicitly designed from the beginning to be bidirectional sync and not backup. There are great backup tools out there. Syncthing is not one of them. Over time we’ve bolted on some unidirectional-ish features but it’s never a fantastic match.

15

@calmh

I know that it is not a backup program. And uni-directional sync is not a synonym for backup :-). Conceptually, there is only a small difference between bi- and uni- directional sync, but there’s a big difference between mere sync and backup.

I know what I’m talking about because a few months ago I implemented uni-directional sync to a (IMO very good) sync script called bsync (GitHub - xarx00/bsync: Bidirectional Synchronization using Rsync). Turning a bi-directional sync into a uni-directional was rather a small change. Of course, I do not know the quirks of ST, so fixing uni-directional sync in ST might be a big problem. But my point is that the code for uni-directional sync is only a 1% of the whole code-base. Why to use another tool that has the rest 99% worse than ST?

Edit: If you abandon uni-directional sync, you’ll have to abandon Android as well, because ST can Send Only there.

16

That’s not actually true, as long as it does not involve SD cards. And I think SD cards are pretty much dead is most modern phones.

Unidirectional sync is not 1% of the code base, it is now, in it’s broken form, but to do it right, I suspect it’s definately more than 1%.

17

Also this is a side track. Unidirectional is not the problem. Send-only and receive-only both implement unidirectionality.

Ignoring deletes is not about unidirectional sync. It’s about “not-sync” – deliberately not syncing some changes to a file that we are otherwise tracking, regardless of the direction.

2 Likes
18

When it comes to Android though, I do not think that there is any other open source application that would do this kind of one-way synchronisation.

2 Likes
19

A contradiction in term, surely?

Don’t try and make a hammer into a screwdriver. Use the tool for the job: sync, ST (brilliant); backup, borgbackup etc (bullet proof}; one-way sync/copy, rsync, rclone etc (proven reliable).

20

Yes, but the same thing can be said about “Send Only” and “Receive Only” folders, which are integral part of Syncthing (and also exposed in the “normal” GUI).

I do not think that these tools are available for Android, or am I wrong?

Unless you write your own bash scripts and play around with scheduling, which itself requires external applications, as Android does not have any build-in tools like cron, etc. Then you also have to deal with networking, which Syncthing takes care of completely (at least with global discovery and relaying enabled).

Sometimes there is simply no screwdriver available.

2 Likes