Windows directory symlinks copied as file symlinks

[isanych]

Opposite to linux, on windows file symlinks and directory symlinks are different type of links, but unison sync directory symlink as file symlink and they could not be used as directories after sync:

C:\>md src\d1
C:\>mklink /d src\d2 d1
symbolic link created for src\d2 <<===>> d1
C:\>unison -batch src dst
Unison 2.53.3 (ocaml 4.14.0): Contacting server...
...
Reconciling changes
dir      ---->
src          : dir                modified on 2023-07-05 at 14:28:22  size 0         read-write
dst          : absent

1 items will be synced, 0 skipped
0 B to be synced from src to dst
0 B to be synced from dst to src
Propagating updates
Unison 2.53.3 (ocaml 4.14.0) started propagating changes at 14:28:45.98 on 05 Jul 2023
[BGN] Copying  from C:/src to C:/dst
[END] Copying
Unison 2.53.3 (ocaml 4.14.0) finished propagating changes at 14:28:45.98 on 05 Jul 2023, 0.002 s
Saving synchronizer state
Synchronization complete at 14:28:45  (1 item transferred, 0 skipped, 0 failed)

C:\>dir src
 Directory of C:\src
07/05/2023  02:28 PM    <DIR>          .
07/05/2023  02:27 PM    <DIR>          d1
07/05/2023  02:28 PM    <SYMLINKD>     d2 [d1]
C:\>dir dst
 Directory of C:\dst
07/05/2023  02:28 PM    <DIR>          .
07/05/2023  02:28 PM    <DIR>          d1
07/05/2023  02:28 PM    <SYMLINK>      d2 [d1]

As you can see dst\d2 is <SYMLINK> instead of <SYMLINKD>, file symlinks synced correctly.

[tleedjarv]

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

[isanych]

the same

C:\>md src\d1
C:\>unison -batch src dst
...
C:\>mklink /d src\d2 d1
symbolic link created for src\d2 <<===>> d1

C:\>unison -batch src dst
Unison 2.53.3 (ocaml 4.14.0): Contacting server...
Looking for changes
Reconciling changes
new link ---->            d2
src          : new symlink        modified on 1970-01-01 at  0:00:00  size 0         unknown permissions
dst          : absent

1 items will be synced, 0 skipped
0 B to be synced from src to dst
0 B to be synced from dst to src
Propagating updates
Unison 2.53.3 (ocaml 4.14.0) started propagating changes at 16:26:30.83 on 05 Jul 2023
[BGN] Copying d2 from C:/src to C:/dst
[END] Copying d2
Unison 2.53.3 (ocaml 4.14.0) finished propagating changes at 16:26:30.83 on 05 Jul 2023, 0.002 s
Saving synchronizer state
Synchronization complete at 16:26:30  (1 item transferred, 0 skipped, 0 failed)

C:\>dir src
 Directory of C:\src
07/05/2023  04:26 PM    <DIR>          .
07/05/2023  04:26 PM    <DIR>          d1
07/05/2023  04:26 PM    <SYMLINKD>     d2 [d1]

C:\>dir dst
 Directory of C:\dst
07/05/2023  04:26 PM    <DIR>          .
07/05/2023  04:26 PM    <DIR>          d1
07/05/2023  04:26 PM    <SYMLINK>      d2 [d1]

[tleedjarv]

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 a test build from https://github.com/tleedjarv/unison/actions/runs/5499769169 (end of page) and see if it changes anything for you?

[isanych]

yep, second scenario creates correct symlink with test build

[gdt]

@isanych Could you add a comment that explains what is problematic with git master (or 2.53.5, if that's hard)? Not claiming that it's all fixed, but I find the current state hard to follow. Really I'd like a replacement opening text that ignores how we got here and says what is wrong as of now, so that people can read that and ignore everything upthread. New issue and closing this one is fine too.