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 using Unison File Sync which itself uses rsync and
doesn't support preserving symlinks between Windows and Unix so I'm
wondering if it's just not possible in which case maybe I'll just have
to live with following symlinks --copy-links.
+ + + + + + + + + + + + + + + + + +
Email: edwinbradford at gmail.com
Tel.: +44 (0)7981 873 771
+ + + + + + + + + + + + + + + + + +
On Tue, 29 Dec 2020 at 16:39, Kevin Korb <kmk at sanitarium.net>
wrote:>
> 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 least that is how it works in *nix.
>
> On 12/29/20 11:34 AM, Edwin Bradford wrote:
> > 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 recreated the Windows symlinks on the source volume
> > using relative paths.
> > 2. I deleted and recreated the same symlinks directly on the
destination
> > volume.
> > 3. I ran the same rsync command with the --archive flag (preserve
symlinks).
> >
> > The result was the symlinks on the destination volume were preserved
or
> > at least not destroyed by the subsequent sync. If this test is what
you
> > intended then it shows rsync can preserve the symlink between NTFS
> > volumes but I would have to manually recreate the symlinks on the
> > destination NTFS volume once.
> >
> > Have I understood correctly?
> >
> >
> > On Tue, 29 Dec 2020 at 13:53, Kevin Korb via rsync
> > <rsync at lists.samba.org <mailto:rsync at
lists.samba.org>> wrote:
> >
> > 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 12/29/20 7:29 AM, Edwin Bradford via rsync wrote:
> > > 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 NTFS volume has symlinks created in Windows using:
> > >
> > > mklink the\link the\file
> > > mklink /d the\link the\directory
> > >
> > > I am running rsync within a long shell script with the
command:
> > >
> > > rsync
> > > --verbose --archive --checksum --itemize-changes
--human-readable
> > > --delete --delete-excluded --partial --progress --stats
> > > --exclude-from='ignore.txt'
> > > source/ destination
> > >
> > > The symlinks are copied to the external NTFS partition and
have
> > the same
> > > name but no functionality. Windows doesn't recognise them
as symlinks,
> > > doesn't know what to do with them and there is no
apparent difference
> > > between symlinked directories and files.
> > >
> > > I tried creating the symlinks with relative paths on the
source volume
> > > but rsync generated an error and refused to complete. Using
> > --copy-links
> > > instead of --links (implicit in --archive) gives the expected
> > behaviour
> > > but I would prefer to preserve symlinks rather than replace
them with
> > > their linked contents.
> > >
> > > At this point I'm not sure if it's a limitation of
rsync and NTFS
> > > compatibility or whether I'm missing something.
> > >
> > > + + + + + + + + + + + + + + + + + +
> > >
> > > Email: edwinbradford at gmail.com <mailto:edwinbradford at
gmail.com>
> > <mailto:edwinbradford at gmail.com <mailto:edwinbradford at
gmail.com>>
> > >
> > > Tel.: +44 (0)7981 873 771
> > >
> > > + + + + + + + + + + + + + + + + + +
> > >
> >
> > --
> >
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
> > Kevin Korb Phone: (407) 252-6853
> > Systems Administrator Internet:
> > FutureQuest, Inc. Kevin at FutureQuest.net
(work)
> > Orlando, Florida kmk at sanitarium.net
> > <mailto:kmk at sanitarium.net> (personal)
> > Web page: https://sanitarium.net/
> > <https://sanitarium.net/>
> > PGP public key available on web site.
> >
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
> >
> > --
> > Please use reply-all for most replies to avoid omitting the
mailing
> > list.
> > To unsubscribe or change options:
> > https://lists.samba.org/mailman/listinfo/rsync
> > <https://lists.samba.org/mailman/listinfo/rsync>
> > Before posting, read:
> > http://www.catb.org/~esr/faqs/smart-questions.html
> > <http://www.catb.org/~esr/faqs/smart-questions.html>
> >
>
> --
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
> Kevin Korb Phone: (407) 252-6853
> Systems Administrator Internet:
> FutureQuest, Inc. Kevin at FutureQuest.net (work)
> Orlando, Florida kmk at sanitarium.net (personal)
> Web page: https://sanitarium.net/
> PGP public key available on web site.
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,