Preserve Windows Symlinks

Edwin Bradford edwinbradford at gmail.com
Tue Dec 29 18:02:17 UTC 2020


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: edwinbradford at gmail.com

Tel.: +44 (0)7981 873 771

+ + + + + + + + + + + + + + + + + +


On Tue, 29 Dec 2020 at 17:52, Kevin Korb <kmk at sanitarium.net> wrote:
>
> 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 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.
> >> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
>
> --
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
>         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.
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,



More information about the rsync mailing list