One-time "sync"

Feature
1

Feature Request – Onetime sync

Some sync tools offer “shared files” or a similar to transfer a folder/file once. A onetime transfer is a very common use case and often a reason to use a sync tool offering it. If devices are connected per syncthing, it would be very handy if a onetime “sync” to specific devices is possible via syncthing. Syncthing could send a notification to (an)other device(s) (of which it already knows the device identification) about a folder/file which is available (until an expiration date has reached) for an onetime transfer and will send it as soon as the recipient agrees.

2

Isn’t this use case handled fine by, like, HTTPS and BitTorrent (not sync, just the regular kind)?

3

There are for sure several possibilities, but people tend to keep it simple and use what they use daily to be able to handle their work quickly. My question is therefore whether a one-time sync is a feasible feature for syncthing.

1 Like
4

I think it’s out of scope if syncthing, and we need to keep the scope tight otherwise things are going to go out if hand, and we’ll be implementing mp3 player, caldav and replacements to other tools that already solve the problem well enough.

5

Yes, implementing “mp3 player, caldav and replacements to other tools” is for sure out of scope. But I’m asking for something close. Not to sync a folder/file permanently, but once, i.e. a transfer. Is it really that far from what syncthing can already do? Since Resilio Sync has been mentioned, it has such a feature in its latest version.

6

How do you define a one off, as in, what does one off actually mean. What if the “one off” files change? Do I loose access after the one off download? Do I keep the device added permanently? How do I establish trust between them? What if the device has only done a partial download? How does the device have access other devices that have the data, if yes, how is the trust established?

There is plenty of questions, and even more design problems.

The way syncthing is implemented and structured now make it pretty much impossible to implement what you are asking for without significant re-engineering.

I don’t think anyone is interested in significant re-engineering when the users can just use email/rsync or one of the other many thousand tools that already solve the problem, instead of shoehorning something into syncthing just because it feels like a simillar problem.

7

I think, it’s not necessary to be that complicated. Devices already linked together by syncthing with their ID are trustworthy – anything else would be strange. I only consider this case, not the connection to any device. Therefore, access and trust is already granted. I’m not sure what “one off” means, but guess if a device is temporarily not accessible. “What if the device has only done a partial download? “ What happens in the permanent sync case? If it arrives it’s done and otherwise the transfer starts again as soon as a connection is established.

“There is plenty of questions, and even more design problems. The way syncthing is implemented and structured now make it pretty much impossible to implement what you are asking for without significant re-engineering. I don’t think anyone is interested in significant re-engineering when the users can just use email/rsync or one of the other many thousand tools that already solve the problem, instead of shoehorning something into syncthing just because it feels like a simillar problem.”

Honestly, this answer gives me rather the impression of a lot of resistance for this suggestion. This is of course ok, but it would be nice to understand, e.g. what more concretely makes it “pretty much impossible” or what has to be “significantly re-engineered”. To me, it seems that syncthing needs for this suggestion basically new the possibility to stop after the first transfer on a folder/file.

8

So I am not exactly sure what you are after. From what you described to me it sounds like a one link you send to someone that allows you to download files once, which is significant re-engineering effort which allows otherwise unauthorized devices, removes them after some condition is met etc.

If it’s something else, you should be more descriptive of how you are expecting this to work, what this achieves and how it does that.

Now it’s just “one time sync” where one time has many interpretations in this context.

9

I’m not sure where “unauthorized devices” are still in play. The use case is on already by syncthing connected and hence already known (and hence trusted) devices. For such connected devices, I suggest the possibility a one-time sync, i.e. the device offering a folder/file sends a notification to a receiving device. If the receiver confirms, the transfer starts. It makes sense to me to have an expiration date until the receiver can confirm. After the first transfer, the sync stops. “Now it’s just “one time sync” where one time has many interpretations in this context.” Which ones do you have additionally in mind?

10

This sounds like two devices already connected and sharing a folder. Copy a file to the folder on one side. It gets transferred to the other side - “one time sync”. The other side moves the file out when it’s received. It gets removed on the original side as well. Otherwise, when the source side feels the file has expired they delete it. One time sync complete? :slight_smile:

If this wouldn’t work for you, you need to better describe how you expect it to work.

This works fine also without the devices sharing the folder beforehand.

  • “A” creates a folder and shares it with “B”. Copies the file to share into it.
  • “B” receives the “A wants to share a new folder with you prompt”.

The rest as above. Remove folder when done.

1 Like
11

Yes, as I understand the first scenario, it’s a static way possible for a few devices, where each has a folder to each other device for that purpose. With an increasing number of devices, this needs then an increasing number of folders between all devices to allow a dedicated one-time sync of files that way. This becomes fast very unhandy.

Yes, with the second scenario a sync-share of a folder is possible as you described it. Your one-time sync is then

(1) “A” creates a folder and copies files into it (2) “A” adds the folder to syncthing and offers it to “B”, “C”, etc. (3) “A” clicks on “Advanced” and choose “Send Only” as “Folder type” (4) “B”, “C”, etc. receives the ““A” wants to share folder <…>.Add new folder?"” (5) “B”, “C”, etc. accept “Add” to access the folder (6) “B”, “C”, etc. create a new folder to link it to that offer (7) “B”, or “C”, etc. copy/move the folder or the files to another place (8) “A” may see now “Out of Sync” for the folder and “Up to Date” for the devices which is for an one-time sync not a proper information (9) “B”, “C”, etc. delete the folder in syncthing (10) “A” has no good information about whether it has been delivered to everyone and keeps the folder for an undefined time. (11) “B”, “C”, etc. who has deleted the folder in syncthing gets again the invitation for that folder they already got. They can decide “Add” or “Later” (12) “B”, “C”, etc. who already got and copied the folder have now to decide whether this is an new invitation or an old one, especially, if a some folder are offered that way (13) Everyone might be on a way to confusion

I suggest

(1) “A” creates a folder and copies files into it (2) “A” adds the folder to syncthing and offers it to “B”, “C”, etc. for “One-Time Sync” and expires at … (3) “B”, “C”, etc. receives the ““A” offers the One-Time share folder <…>. Accept?"” (4) “B”, “C”, etc. accept to access the folder (5) “B”, “C”, etc. point to a folder into which the “One-Time Sync” will be copied (it already has a name given by “A”) (6) “A” gets the information that “B”, “C” got the folder and after everyone got it (or the expire date arrives), syncthing deletes that “One-Time Sync” share at “A” (but not the folder) (7) Whatever “B”, “C” are doing else with the folder after its delivery has no further (informational) effect on “A” nor do “B”, “C” etc. get the invitation another time

12

What you described is essentially the existing folder that just gets unshared (and eventually removed?) as devices hit 100% or some time comes.

You can write a small script that implements this by using/monitoring the REST API on top of syncthing.

I think this feature would have too few users to be worthwhile to include in syncthing.

13

Or do what you described in the second scenario, but set the folder on “A” to send only. Share it with B and C. Add files to send to those devices. There is no step 4, 5, 6 etc, just leave the setup as is.

14

In the simplest realization which covers this use case user friendly, when “A” offers a folder for one-time sync to “B”, “C”, etc. at “Advanced” there can be additionally “Send Once” as “Folder type”. An expire date will restrict the delivery. Additionally needed is “A” recognizes the delivery or its denial and stops then the sync/delivery. When the expire date has reached, the sync/delivery will be disabled on “A” and stops. This use case is widely mentioned in discussions I have. There is for sure a hack, but this is then not user friendly and therefore not useful.

15

I guess I just don’t understand the point, really. The only things lacking today, as I understand it, is the automatic expiry thing. Given that this is the first time I’ve run into that requirement it seems like something that should be scripted on top of Syncthing as a proof of concept, then if that seems popular it could be integrated into Syncthing.

The “one time” thing is easily solved by simply not changing the file on the source and setting the folder to send-only: if the file is not changed, and no changes are accepted form the outside, it will only be synced once.

Recognizing whether it’s sent or not is already done by way of the completion percentages. Stopping the “delivery” once it’s sent is not required as the file isn’t changed and thus will only get delivered once…

16

Yes, for this use case, what it lacks today is the automatic expiration date, but secondly an automatic disabling of sync/delivery. If people, just do nothing with the delivered items everything is fine, but a user will work with it which leads to misinformation (e.g. “Out of Sync”). This could be addressed e.g. by “B”, “C” etc. see “Delivered” instead of “Up to date” and “A” has “Is delivered”. But basically, no misinformation is sufficient. I think that this is rather a small extension on syncthing. I don’t know what you mean with “scripting”, but it gives me the picture of a complicated work-flow for an averagely unexperienced user. Then it won’t be used.

17

I think it’s more complicated that it sounds as it requires exceptions to the fundamentals of how Syncthing operates. As such, I doubt it will get implemented. Everyone is free to prove me wrong, of course.

18

Ok, can you please give an example for “exceptions to the fundamentals of how Syncthing operates” that makes me understanding it? Thank you.

19

Syncthing is designed around semi-permanent relations between devices, with changes continuously synced in both directions. Making folder associations temporary and time limited and preventing changes from being synced are all exceptions that break assumptions in the code.

20

Ok, you point me deep into coding. So, can you please point me to one of those parts where the semi-permanent relations is coded? Thanks again.