Preserve Windows Symlinks

Tue Dec 29 17:52:23 UTC 2020

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.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,