Actually - is there a reason why we need the platform specific commands here?
I have just tested running simply like that:

Future<File> createShortcut(Directory location, File target) async {
  final name = p.basename(target.path);
  final link = findNotExistingName(File(p.join(location.path, name)));
  // this must be relative to not break when user moves whole folder around:
  // https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/issues/232
  final targetRelativePath = p.relative(target.path, from: link.parent.path);
  return File((await Link(link.path).create(targetRelativePath)).path);
}

12821/12821 files, no errors, all symlinks are relative, Windows 10 x64.

siema maczuga

sluchaj pytanko, czy jak sie tworzy takie symlinki na windozie to to ładnie działa, wszystko jest widać w plikach/na pulpit to można dać? jeśli tak to możemy na nie totalnie przejść

jeśli by sie okazało że on jak sie kopiuje np na FATa to to zamienia na fatowe symlinki itp, to jeszcze zajebiściej

Na szybko sprawdziłem to co mam teraz - symlinki generowałem właśnie #249 (comment)

Jak dałem ctrl+x -> v (wytnij/przenieś) na 2 katalogi - powiedzmy Album1 i ALL_PHOTOS z folderu Takeout np. na root dysku - to relatywność mi się zachowała - i mogłem symlinkami wchodzić dalej w oryginały zdjęć (w folderze TakeoutOut - tam gdzie skrypt puścił output - nie było już ALL_PHOTOS, więc symlink poprawnie kierował na powiedzmy E:/ALL_PHOTOS zamiast E:/TakeoutOut/ALL_PHOTOS).

Za to kopiowanie symlinków w tym przypadku (za pomocą explorera) - w miejscu docelowym pojawiały się już nie symlinki - a były one zastąpione gotowym plikiem.

Jutro spróbuję jakiś mniejszy repro-case zrobić, bo na 130GB danych średnio się kopiuje/testuje.