Fix relative "shortcuts" in Windows - #249
Conversation
Apparently there is no support for relative shortcuts in Windows. Use symlinks instead thus fixing the relative paths.
|
Actually - is there a reason why we need the platform specific commands here? 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. |
|
I tried this version on Windows 11, but I get an error when it tries to create symlinks. I think it's because administrator rights are required (or dev mode), because after I ran gpth in admin mode, it created the symlinks correctly. I made a commit that, if its Windows, uses absolute paths, and it works fine, though it creates shortcuts instead of symlinks, but it resolves these issues: master...Wacheee:GooglePhotosTakeoutHelper:shortcutFixWindows Future<File> createShortcut(Directory location, File target) async {
final name = '${p.basename(target.path)}${Platform.isWindows ? '.lnk' : ''}';
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);
final targetPath = target.absolute.path;
if (Platform.isWindows) {
final res = await Process.run(
'powershell.exe',
[
'-ExecutionPolicy',
'Bypass',
'-NoLogo',
'-NonInteractive',
'-NoProfile',
'-Command',
'\$ws = New-Object -ComObject WScript.Shell; '
'\$s = \$ws.CreateShortcut(\'${link.path}\'); '
'\$s.TargetPath = \'$targetPath\'; '
'\$s.Save()',
],
);
if (res.exitCode != 0) {
throw 'PowerShell doesnt work :( - '
'report that to @TheLastGimbus on GitHub:\n\n'
'https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper/issues\n\n'
'...or try other album solution\n'
'sorry for inconvenience :(';
}
return File(link.path);
} else {
return File((await Link(link.path).create(targetRelativePath)).path);
}
}mmm maybe in Windows can be an option to choose between symlink (but admin right is required) and shortcut (no admin rights required) |
3 participants
Apparently there is no support for relative shortcuts in Windows. Use symlinks instead thus fixing the relative paths.
Fixes #248