Open Maczuga opened 9 months ago
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 https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/pull/249#issuecomment-1740991747
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.
Apparently there is no support for relative shortcuts in Windows. Use symlinks instead thus fixing the relative paths.
Fixes #248