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: edwinbradf...@gmail.com > > Tel.: +44 (0)7981 873 771 > > + + + + + + + + + + + + + + + + + + > > > On Tue, 29 Dec 2020 at 16:39, Kevin Korb <k...@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@lists.samba.org <mailto:rsync@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: edwinbradf...@gmail.com <mailto:edwinbradf...@gmail.com> >>> <mailto:edwinbradf...@gmail.com <mailto:edwinbradf...@gmail.com>> >>> > >>> > Tel.: +44 (0)7981 873 771 >>> > >>> > + + + + + + + + + + + + + + + + + + >>> > >>> >>> -- >>> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., >>> Kevin Korb Phone: (407) 252-6853 >>> Systems Administrator Internet: >>> FutureQuest, Inc. ke...@futurequest.net (work) >>> Orlando, Florida k...@sanitarium.net >>> <mailto:k...@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. ke...@futurequest.net (work) >> Orlando, Florida k...@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. ke...@futurequest.net (work) Orlando, Florida k...@sanitarium.net (personal) Web page: 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 Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
