Add feature to rewrite symlinks

[navid-zamani]

This is a useful thing I’ve seen elsewhere. (I think Apache’s rewrite rules.)
On my system, some symlinks are absolute, but point right back to a place in the same directory that is synced from/to. They can be transparently rewritten by replacing the base directory in all absolute softlinks to paths that don’t exist on the target system. Or by making them relative. But that has problems I think.

An option “rewrite-symlinks” of type list, with sub-options of type “rule” that specify the (simple) rewrite pattern, would be great. If one messes up then, one at least knows to blame oneself. :)
Possible include:

• Change absolute base directories (Very simple to implement, as it always starts at the beginning.)
• Turn absolute links into relative ones for the purposes of the sync (This is probably the most common use, and I remember having used it in either Apache or Samba before.)
• rename a specific directory (E.g. in my case, the Android phone has fixed names for certain directories, but on my PC I do not want those names (not only due to it not being English).)

Of course this should not be the default, but a switch with the appropriate info of the rare but possible case of above checks leading to the rewrite not being fully transparent.

In my case, I already tried changing the symlinks to relative from the start. But for certain situations, that is not reasonable. E.g. because the directories those symlinks are in, are moved themselves. So the relative paths they point to would have to be changed each time.
(In general it is really sad, that Linux went with no support for circular loops in the file system structure via directory hardlinks. I tried forcing it, by using a mirroring FUSE mount, and it literally crashed the kernel. Without root! … Meanwhile, this software design problem was solved for data structures in general, before I was even born! [The gist: Don’t use reference counting. Ever. Trace walked paths and stop when encountering the same one twice, instead.])

[gdt]

I am trying to limit comlexity and unison is already too complicated. Please feel free to discuss on hackers if you are inclined to implement this and submit a PR. If not, I'll likely just move this to the list of enhancement requests that are unlikely to happen, as available effort on unison is going to bug triage, fixing things that are really troublesome and improving things with very broad benefit.

[navid-zamani]

I am trying to limit comlexity and unison is already too complicated.

Well, in that case how about going all the way, and replacing the entire code by a single NOP instruction? It is less complicated, so clearly it is better! XD
Joking aside, I presume you meant it has too low emergence (= too little bang for the buck). So the first thing I’d do, is not put the documentation inside the program, and separate the UIs into their own frontend programs, so unison can be a nice clean daemon. :) This would even allow the UI to run on a different system, by piping the daemon’s command interface over the same SSH pipe; allowing a server to initiate a sync, but still have the GUI on the user’s PC.

I don’t think symlink rewriting is complexity per se. More an aspect of a generic mapping of system-specific properties, as is already done with FAT and Windows quirks. Maybe that can be removed too, by just using external callbacks in that phase, like with the copyprog functionality. So you’d actually end up with less code to maintain. :)

Anyway, I now worked around this, by creating the path (that exists on the phone) on my PC too, and altering all symlinks to point to that. So they end up correct when synced to the phone. So this is solved for me; albeit in an ugly way. Maybe it’s useful for somebody else…

[tleedjarv]

I personally like this feature request. I don't need it myself but I think it makes sense and is rather easy to implement (testing is where most of the effort is going to be). That said, I'm not going to implement it myself right now but I think it deserves to be in the feature request list. It'd definitely help if several people show interest in this.

separate the UIs into their own frontend programs, so unison can be a nice clean daemon. :) This would even allow the UI to run on a different system, by piping the daemon’s command interface over the same SSH pipe; allowing a server to initiate a sync, but still have the GUI on the user’s PC.

This (and some more) is exactly what I've wanted for a couple of years now. I don't know if I'll ever have time to actually implement something... but the dream is there :)