ignoreDelete is available but ignoreUpdate not

Support
1

I need to add files only, so remote host (which is receive only) should create files only once (not update it).

It means if local copy is damaged (updated) accidentally then remote copy will not be affected.

In normal situation files should be read and added only, so never updated or deleted. But I have to directly disable such possibility.

I can try to achieve that by FS permissions. But on Linux I have to run additional commands after file creation (not sure if Syncthing can do that), and not clear how Syncthing will work with IO error due to permissions.

2

I suggest rsync --ignore-existing. Syncthing is not shaped like the hole you want to fill.

3

It will not work because SSH will allow to update\delete files.
In addition it will require maintenance of 2 separate ways to connect remote host.

Why is ignoreDelete present but ignoreUpdate not? If delete is ignored to keep files then their content still can be damaged by writing to file. In other words it can be truncated to zero.

Alternatively I can try to enable version history. So I will be able to find all required files there.

Will history keep deleted files?

4

Versioning could help, but I’m not sure there is a versioning strategy that guarantees the original version is kept forever if there are a thousand updates to a file subsequently.

5

Effectively, ignoreDelete should not exist, but the cat is out of the bag and we can’t remove it.

2 Likes
6

I prefer to get one more cat ))

But OK, what is the alternative?
How to achieve desired behaviour? How to protect one-way copied files?
If even versioning cannot keep versions forever…

Can Syncthing apply command to target of synchronization when process finished?
It there any way to subscribe to sync events?

P.S. I am trying to use it in real-world scenario and I am very “unlucky” with Syncthing.

7

I’d suggest External Versioning in this case. This way you can write your own scripts to handle the files, so that nothing will get deleted without your explicit permission.

8

I think you are simply using the wrong software. Syncthing is not a distribution mechanism, its sync software, it propagates changes bidirectionally.

Rsync is probably more suitable for the job

9

Maxim, have you read up on and tested rsync? It’s man-page says:

--ignore-existing       skip updating files that exist on receiver

And:

-b, --backup                make backups (see --suffix & --backup-dir)

It has been said before: Syncthing is not a backup tool.

10

martinleben, rsync needs SSH, providing SSH access makes remote backups not immutable, SSH allows to connect to remote and damage whatever, so if local copy is compromised then remote is compromised as well.

I do not use Syncthing for backups, I simply need a remote copy of files which are immutable and should not be deleted by source.

11

It is not true. Folder types: Send/Receive allow to make it unidirectional.

So I just asked about more control over sync process.
In addition to make it receive only I need to make it immutable.
In other words “Receive Once”.

12

Granted, yes you need ssh access.

Regarding immutability: Run rsync on the remote end instead, pulling the files from the source. That way you have control over the rsync arguments.

1 Like
13

Granted, yes you need ssh access.

Regarding immutability: Run rsync on the remote end instead, pulling the files from the source. That way you have control over the rsync arguments.

It is meaningless and I would even say the harmful advice.

14

Why?

15

Because you suggest to give access via SSH. It is dangerous, at least considering what I wrote in topic of this thread. So that ruins original idea to have “Receive Once” (or ignoreUpdate). With SSH you can do whatever, so somebody can read that and consider as real alternative but it is not.

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.