Tõivo Leedjärv

I think the suspicion was correct, this and #780 have the same underlying cause. The cause is that all the transport threads (Lwt threads, not real threads) are created together...

> It seems making one thread per item up front is bad strategy Agree. This is what probably causes the stack overflow in #780 (**Edit:** also, the stack in that...

It's the same code that is responsible for #396. It makes sense to keep the discussion there in one place.

Could you try the following and report the results? ``` C:\>md src\d1 C:\>unison -batch src dst C:\>mklink /d src\d2 d1 C:\>unison -batch src dst C:\>dir src C:\>dir dst ```

Properly fixing this is going to be a larger change. For now, I have a partial fix that should at least fix the second scenario here. @isanych Could you try...

I think the request is valid and should remain open (this would also be a good issue for a new contributor to tackle!). In an attempt to explain very shortly,...

There are several issues (or areas of potential improvement) here. First, the lack of inplace update, which not only causes a lot of extra I/O but also ruins fs block-level...

I've opened a PR with a proof-of-concept alternative solution to this request. See #876. Granted, it only works in some configurations (must have platform and filesystem support) but when it...

I could potentially help with the code, given that a specification is provided for how this should work on each platform (I guess XDG, macOS, Windows is what we need)....

It is not unthinkable to implement support for rsync's fake-super xattr directly in Unison (assuming there is a stable spec for that xattr). (_Edit:_ The xattr data format is super-simple...