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