Is it possible to preserve Windows symlinks when backing up from NTFS to
NTFS volumes or any other for that matter?
I am running rsync in Ubuntu in Windows Subsytem for Linux on Windows 10
backing up a local NTFS volume to an external NTFS volume (and also to a
remote Unix server).
The source NTF
If you delete the link then restore it does it start working again when
in the correct place?
Also, don't use --checksum unless you are really certain you understand
how terribly slow it is and how it doesn't actually accomplish much of
anything (certainly not any kind of data verification).
On 1
Yes I found --checksum is much slower so following your feedback I'll do
some more reading to see if I really need it thanks. Assuming I understand
correctly I did the following test and also replaced absolute symlink paths
with relative symlink paths which worked this time:
1. I deleted and recre
Not quite. I meant rsync a symlink then delete the source symlink and
use rsync to restore it from what rsync made. If the target of the
symlink doesn't exist on the other system (in the same place) then the
symlink shouldn't work on the remote but rsync can still backup it up
and restore it. At
Sorry, I should have realized, that makes complete sense in hindsight.
I deleted the original source volume symlink and restored from the
external volume symlink and the same problem exists... Windows doesn't
recognise it as a symlink or appear to know what kind of file it is.
Previously I was usi
Unison doesn't use rsync it only uses librsync (rsync's file diffing
algorithm). Also, unison has a native Windows version so no *nix
translation is needed.
On 12/29/20 12:48 PM, Edwin Bradford wrote:
> Sorry, I should have realized, that makes complete sense in hindsight.
> I deleted the origina
I didn't know that thanks. I was using Unison for years but there's a
recent conflict with the latest version of OpenSSH built in Windows
and although there's a workaround as I use Windows Subsytem for Linux
I decided to just switch to rsync instead.
+ + + + + + + + + + + + + + + + + +
Email: e