[FR] add option to merge received directories with local directories

E.g., the remote sends a/ which has two files a/b/1.txt and a/b/2.txt, but we already have the file a/b/d.txt locally. This currently fails because the local directory already exists.

[meejah]

Interesting!

Brian and I have talked a little about something similar for Dilation (e.g. to allow other applications to play around with it w/o having to have a Dilation-supporting library for their language).

Thinking out loud, I wonder if SOCKS5 could be an appropriate interface here? It might be stretching the semantics of that protocol a little, but a new connection opening a new sub-channel in Dilation would be the rough idea.

In any case, the point is I’d be a lot more interested in exploring these (port-forwarding, SOCKS5, …?) as ways to inter-operate with existing applications rather than adding “rsync” features to the Python CLI.

At a high level, the “UX ask” here is reasonable: “synchronize two folders”. I just don’t think that complexity should live in this code-base. (So, that said, if there are good Python libraries for synchronizing files perhaps this could be a use-case for next-generation file transfer … that is, the Dilation-based protocol).

[meejah]

I agree that “synchronizing folders” isn’t exactly a use-case of magic-wormhole (although that said, it does of course fall under the general umbrella of “send files places”).

@piegamesde is certainly correct that this isn’t as straightforward as it might appear at first. What do you do when a transferred file exists on the target, but is different content? (Among other considerations of course). What if the sender has a directory called a/foo but a/foo exists as a file on the target?

One approach that might be fruitful would be to take some existing synchronization tool (e.g. rsync) and teach it how to use magic-wormhole to set up connections (rather than e.g. ssh as it does currently). I think this would probably be far more straightforward on top of Dilation because two-way communication is typically required to get synchronization correct . I don’t know rsync well enough to know how “pluggable” its transport might be, so this is just a general idea/example.

A key advantage of this would be the potential to re-use the approach for other tools. That is, specifying how to use magic-wormhole as a secure transport. (This may require additional features in magic-wormhole as well as possibly other tools of course). I would personally be a lot more excited to implement it this way instead of creating another rsync-like tool

I’m not aware of any Python implementation of general file-synchronizaiont; if you know of any such libraries please post them.