I am writing some PowerShell scripts for my own use to handle initializing of repositories and backups…
I prefer to create separate folders for each repository and use NTFS Junctions to point to actual source folders. (It is much easier to manage sources this way while duplicacy insists on using current folder for repository).
But I am running into the issue - PowerShell 5.1 new-Item creates junctions a bit differently compared to mklink command… For the rest of the OS they are the same, but duplicacy does not follow those links!
Here is how to reproduce and see the difference:
c:\temp>powershell
......
PS C:\temp> & cmd.exe /c mklink /j use-mklink c:\users
Junction created for use-mklink <<===>> c:\users
PS C:\temp> New-Item -ItemType Junction -Path use-new-item -Target c:\users
Directory: C:\temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 1/4/2020 11:53 PM use-new-item
PS C:\temp> & cmd.exe /c dir /l
......
01/04/2020 11:52 PM <JUNCTION> use-mklink [c:\users]
01/04/2020 11:53 PM <JUNCTION> use-new-item [\??\C:\users]
…
(I removed some wasted space from output)
You can see the difference in the dir output - junction, created with New-Item has “??” in front of the target. This breaks duplicacy logic on following symlinks - it will skip such links.
Not sure who’s actual fault this is. On one hand, I’d expect PS to create same links as mklink, but it still creates completely valid, correct and usable links for NTFS, on the other hand, duplicacy has its own logic for handling these and probably was never tested with such links which are created with full absolute path syntax…
Anyone knows how to make New-Item behave the same as mklink? Don’t really want to call mklink when native option exists…