Re: rsync replacing symlinks without warning (resend)

' -> '/usr/lib' symlinks to be replaced with '/lib' directories, which left the receiving test machines in a fairly sad state. I have since figured out that I can get rsync to behave as expected by adding the --keep-dirlinks option, but ... it's very unfortunate that when rsync does that k

Re: rsync replacing symlinks without warning (resend)

is called as follows: > > > >rsync --verbose --recursive --relative --delete a/./lib/modules b/ > > > > Directory b contains a 'lib' symlink pointing to 'usr/lib', and rsync > > removes that and replaces it with a directory. > > > > In my real-world use case, t

Re: rsync replacing symlinks without warning (resend)

usr/lib' symlinks to be replaced with '/lib' directories, which left the receiving test machines in a fairly sad state. I have since figured out that I can get rsync to behave as expected by adding the --keep-dirlinks option, but ... it's very unfortunate that when rsync does that kind of th

rsync replacing symlinks without warning (resend)

/ Directory b contains a 'lib' symlink pointing to 'usr/lib', and rsync removes that and replaces it with a directory. In my real-world use case, this caused '/lib' -> '/usr/lib' symlinks to be replaced with '/lib' directories, which left the receiving test machines in a fairly sad state. I have si

Re: [PATCH] Fix the counting of device files and symlinks

On Tue, May 16, 2023 at 7:28 PM Marc Aurèle La France via rsync < rsync@lists.samba.org> wrote: > Device files should be counted as devices, not symlinks. > Thanks for the catch! I fixed this the other day. ..wayne.. -- Please use reply-all for most replies to avoid omitting the

[PATCH] Fix the counting of device files and symlinks

Device files should be counted as devices, not symlinks. Marc. diff -aNpRruz -X /etc/diff.excludes rsync-3.2.7/delete.c devel-3.2.7/delete.c --- rsync-3.2.7/delete.c2020-06-13 20:15:02.0 -0600 +++ devel-3.2.7/delete.c2020-06-13 20:15:02.0 -0600 @@ -188,7 +188,7

Re: --copy-unsafe-links unexpected behavior with unsafe symlinks

On Sun, Nov 28, 2021 at 12:53 PM Cristian via rsync wrote: $ rsync --copy-unsafe-links -avz --delete tree XXX In this case, the "tree" directory is a part of the transfer inside the top-of-transfer dir (the current directory). Thus any symlinks that don't try to escape t

Re: --copy-unsafe-links unexpected behavior with unsafe symlinks

To be extra clear (since I was overly terse in my hasty answer), here's your last example fixed for you: $ cd ~/dev $ rsync --copy-unsafe-links -aivz --delete ~/tmp/TST/tree/ ~/tmp/XXX/tree/ This is how rsync knows where the safe restriction lies -- at the top of the transfer (the final

Re: --copy-unsafe-links unexpected behavior with unsafe symlinks

Read the section on --copy-unsafe-symlinks and make the change I recommended. That's all there is to it. When a dir name is in the transfer, it is not the top of the transfer tree. It's parent is. This is pretty standard rsync stuff, where trailing slashes are very important to rsync. ..wayne

Re: --copy-unsafe-links unexpected behavior with unsafe symlinks

unsafe links: Symbolic links are considered unsafe if  they  are  absolute symlinks (start with /), empty, or if they contain enough ".." components to ascend from the directory being copied.    In my case  (I copy and paste below my original example for commodit

Re: --copy-unsafe-links unexpected behavior with unsafe symlinks

On Sun, Nov 28, 2021 at 12:53 PM Cristian via rsync wrote: > $ rsync --copy-unsafe-links -avz --delete tree XXX > In this case, the "tree" directory is a part of the transfer inside the top-of-transfer dir (the current directory). Thus any symlinks that don't try to escape the c

--copy-unsafe-links unexpected behavior with unsafe symlinks

147  speedup is 0.28 As we can see from the output rsync makes a copy of tree/lnk-ans.txt According to the documentation this is correct. --copy-unsafe-links instructs rsync to make copies of the files outside the copied tree. But the same should happen for     tree/o1-file.txt     tree/o

[Bug 10629] rsync follows symlinks that point to same directory / endless loop

https://bugzilla.samba.org/show_bug.cgi?id=10629 --- Comment #2 from Kevin Korb --- Since find is one of the few utilities that actually corrects for symlink loops you can use it as a workaround. Something like: cd /source/path ; find -L . -print | rsync ... --copy-links --files-from=- ./

[Bug 10629] rsync follows symlinks that point to same directory / endless loop

https://bugzilla.samba.org/show_bug.cgi?id=10629 Timothee Besset changed: What|Removed |Added CC||tt...@ttimo.net --- Comment #1 from

[Bug 14683] failed to set permissions on symlinks; need `--omit-link-permissions` option

https://bugzilla.samba.org/show_bug.cgi?id=14683 --- Comment #2 from Ciprian Dorin Craciun --- (In reply to Ciprian Dorin Craciun from comment #1) Trying to `strace` what `rsync` does in my OpenAFS use-case I've found that the only syscals invoked by `rysync` (and pertaining to the file in

[Bug 14683] failed to set permissions on symlinks; need `--omit-link-permissions` option

https://bugzilla.samba.org/show_bug.cgi?id=14683 --- Comment #1 from Ciprian Dorin Craciun --- I've encountered a similar situation, but with OpenAFS, which for some reason reports the protection for symlinks as `rwxr-xr-x`. Thus using `rsync` with `--perms` and targeting an OpenAFS folder

[Bug 14683] New: failed to set permissions on symlinks; need `--omit-link-permissions` option

https://bugzilla.samba.org/show_bug.cgi?id=14683 Bug ID: 14683 Summary: failed to set permissions on symlinks; need `--omit-link-permissions` option Product: rsync Version: 3.2.0 Hardware: All OS: All

Re: Preserve Windows Symlinks

sts... 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 poss

Re: Preserve Windows Symlinks

'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: edwinbrad

Re: Preserve Windows Symlinks

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

Re: Preserve Windows Symlinks

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

Re: Preserve Windows Symlinks

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

Re: Preserve Windows Symlinks

). 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 a

Preserve Windows Symlinks

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

[Bug 5820] make rsync update symlinks/devices/specials atomically

https://bugzilla.samba.org/show_bug.cgi?id=5820 Wayne Davison changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 Wayne Davison changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

|--- |WORKSFORME --- Comment #4 from Wayne Davison --- As long as "munge symlinks = false" is set for your module (which is the default with "use chroot = true" and a normal path value is set), then rsync doesn't tweak the symlinks in the transfer at all. -- You are

[Bug 13920] --max-delete and dirs being replaced by symlinks on source

https://bugzilla.samba.org/show_bug.cgi?id=13920 Wayne Davison changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW

[Bug 13920] New: --max-delete and dirs being replaced by symlinks on source

https://bugzilla.samba.org/show_bug.cgi?id=13920 Bug ID: 13920 Summary: --max-delete and dirs being replaced by symlinks on source Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW

[Bug 10494] remove-source-files fails with symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10494 --- Comment #5 from Adrian Torregrosa --- I embedded the modified sender.c into 3.1.3's original source code, compiled and tested, and I found it to have solved the problem: first I tried uploading a softlink and deleting, then I tried uploading a

[Bug 13827] despite --copy-unsafe-links, rsync does not copy the referent of symlinks that point one level outside the copied tree

to copy the referent of symbolic links that point outside the copied tree. Absolute symlinks are also treated like ordinary files, and so are any symlinks in the source path itself when --relative is used. This option has no additional effect if --copy

[Bug 13827] despite --copy-unsafe-links, rsync does not copy the referent of symlinks that point one level outside the copied tree

|RESOLVED --- Comment #1 from Wayne Davison --- In the command: rsync --archive --copy-unsafe-symlinks home ../rootdir2 The top dir in the tree is "." with "home" being something that you want to transfer in that tree. Thus, anything in that tree is fair game

[Bug 10494] remove-source-files fails with symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10494 --- Comment #4 from Wayne Davison --- In my prior testing I apparently missed that the symlink verification issue was caused by -L (--copy-links). I have amended the change to use do_stat() when --copy-links is enabled. -- You are receiving

[Bug 10494] remove-source-files fails with symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10494 --- Comment #3 from Adrian Torregrosa --- Another option that I tried and verified, and that could make more sense, would be to replace 141 if (do_lstat(fname, ) < 0) { with 141 if (do_stat(fname, ) < 0) { -- You are receiving

[Bug 10494] remove-source-files fails with symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10494 --- Comment #2 from Adrian Torregrosa --- We have found this same problem using rsync 3.1.2. I have downloaded the source code for version 3.1.3, and found the following lines in sender.c: 146 if (S_ISREG(file->mode) /* Symli

[Bug 13827] New: despite --copy-unsafe-links, rsync does not copy the referent of symlinks that point one level outside the copied tree

https://bugzilla.samba.org/show_bug.cgi?id=13827 Bug ID: 13827 Summary: despite --copy-unsafe-links, rsync does not copy the referent of symlinks that point one level outside the copied tree Product: rsync

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 --- Comment #4 from Michael Hipp --- (In reply to Kevin Korb from comment #3) Thanks for the explanation. I would encourage someone to consider updating the documentation to be more like what you wrote - as what I get from reading the man page is

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 --- Comment #3 from Kevin Korb --- I believe I talked to you in IRC about which is why I didn't respond when this was first posted but I think I can help explain this better... The --list-only option is to turn rsync into a network capable ls.

[Bug 13615] Output of --list-only not as I expected re: symlinks

quot;. It would seem to be a viable way to list the files that rsync will consider as candidates to transfer. It obeys the exclusions and such, why does it not obey such for its treatment of symlinks? Using --dry-run isn't really a substitute as it requires a connection to the remote server (destination) i

[Bug 13615] Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 Wayne Davison changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 13615] New: Output of --list-only not as I expected re: symlinks

https://bugzilla.samba.org/show_bug.cgi?id=13615 Bug ID: 13615 Summary: Output of --list-only not as I expected re: symlinks Product: rsync Version: 3.1.3 Hardware: x64 OS: Linux Status: NEW Severity

Re: Output of --list-only not as I expected for symlinks

didn't know it cared about exclude rules but you are right that it >> does.  Guess I never tried.  I only ever used it when I was trying to >> see what was on an rsync server. >> >> Anyway, if you want to list all the files and dirs but not symlinks and >> others in a local

Re: Output of --list-only not as I expected for symlinks

server. Anyway, if you want to list all the files and dirs but not symlinks and others in a local tree: find /path -type f -or -type d -print (or -ls) On 09/12/2018 07:53 PM, Michael Hipp via rsync wrote: Thank you. But I'm afraid I don't understand. The man entry reads: "--list-only

Re: Output of --list-only not as I expected for symlinks

to list all the files and dirs but not symlinks and others in a local tree: find /path -type f -or -type d -print (or -ls) On 09/12/2018 07:53 PM, Michael Hipp via rsync wrote: > Thank you. But I'm afraid I don't understand. The man entry reads: > > "--list-only >     This

Re: Output of --list-only not as I expected for symlinks

uot;list remote files". In fact I am not sure why it would even contact the remote end. And the behavior does not change even if no destination is specified. As far as it ignoring the rest of the command line, note that it does obey exclusion rules. Symlinks seem to be the only anomaly in

Re: Output of --list-only not as I expected for symlinks

ted as regards symlinks. Here > are my test files: > > $ ls ./src > -rw---  1 michael michael    0 2018-09-05 09:18:15 file > lrwxrwxrwx  1 michael michael    4 2018-09-05 09:18:28 near_symlink -> file > lrwxrwxrwx  1 michael michael   23 2018-09-05 09:19:05 far_symlink ->

Output of --list-only not as I expected for symlinks

The output of --list-only isn't as I expected as regards symlinks. Here are my test files: $ ls ./src -rw--- 1 michael michael0 2018-09-05 09:18:15 file lrwxrwxrwx 1 michael michael4 2018-09-05 09:18:28 near_symlink -> file lrwxrwxrwx 1 michael michael 23 2018-09-05 09:19

[Bug 13569] New: --link-dest may follow symlinks and failure to hard link a non-regular file is fatal

https://bugzilla.samba.org/show_bug.cgi?id=13569 Bug ID: 13569 Summary: --link-dest may follow symlinks and failure to hard link a non-regular file is fatal Product: rsync Version: 3.1.3 Hardware: All OS

BUG: --link-dest may follow symlinks and failure to hard link a non-regular file is fatal

Hi, following the instructions on https://bugzilla.samba.org/createaccount-save.html, I've applied for a bugzilla account at bugzilla-maintena...@samba.org but didn't receive a reply, so I report through this list. With --link-dest the search for a candidate to link from, follows symlinks

Re: [Bug 13364] rsyncd clips trims relative symlinks outside of source tree

On 04/04/18 20:52, just subscribed for rsync-qa from bugzilla via rsync wrote: > https://bugzilla.samba.org/show_bug.cgi?id=13364 > > --- Comment #3 from Chris Severance <samba.sever...@spamgourmet.com> --- >> enable munge-symlinks. That way the client will get back the

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 --- Comment #3 from Chris Severance <samba.sever...@spamgourmet.com> --- >enable munge-symlinks. That way the client will get back the same out-of-tree >symlink as it started with This is a lousy option for backups. The only w

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 --- Comment #2 from Dave Gordon --- Comment on attachment 14099 --> https://bugzilla.samba.org/attachment.cgi?id=14099 setup instructions and copier Having set up an rsync daemon (on localhost:10873): $ # Initial fetch of

[Bug 13364] rsyncd clips trims relative symlinks outside of source tree

_symlinks ... When this parameter is disabled on a writable module and "use chroot" is off (or the inside-chroot path is not "/"), incoming symlinks will be modified to drop a leading slash and to remove ".." path elements that rsync believes will allow a s

[Bug 13364] New: rsyncd clips trims relative symlinks outside of source tree

https://bugzilla.samba.org/show_bug.cgi?id=13364 Bug ID: 13364 Summary: rsyncd clips trims relative symlinks outside of source tree Product: rsync Version: 3.1.3 Hardware: x64 OS: Linux Status

[Bug 11949] A malicious sender can still use symlinks to overwrite files

https://bugzilla.samba.org/show_bug.cgi?id=11949 Vitezslav Cizek changed: What|Removed |Added Status|NEEDINFO|CLOSED

[Bug 11949] A malicious sender can still use symlinks to overwrite files

https://bugzilla.samba.org/show_bug.cgi?id=11949 --- Comment #3 from Vitezslav Cizek --- (In reply to Wayne Davison from comment #2) Thanks, I just found the commit too, I completely missed it before. I reproduced this on a patched 3.1.1, not 3.1.2, if I remember it correctly.

[Bug 11949] A malicious sender can still use symlinks to overwrite files

https://bugzilla.samba.org/show_bug.cgi?id=11949 --- Comment #2 from Wayne Davison --- FYI, the other commit is: e12a6c087ca1eecdb8eae5977be239c24f4dd3d9 -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to

[Bug 11949] A malicious sender can still use symlinks to overwrite files

https://bugzilla.samba.org/show_bug.cgi?id=11949 Wayne Davison changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1

[Bug 11949] New: A malicious sender can still use symlinks to overwrite files

https://bugzilla.samba.org/show_bug.cgi?id=11949 Bug ID: 11949 Summary: A malicious sender can still use symlinks to overwrite files Product: rsync Version: 3.1.2 Hardware: All OS: All Status

Re: Deleted symlinks when receiveing files with the same name

Hi list, some advices on that? Regards. On 16/03/2016 16:30, Gionatan Danti wrote: Hi list, I would like to know if the following rsync's behavior can be changed/modified. I noticed that when rsync receive a file for which the local filesystem already has a symlinks with the same path/name

Re: Deleted symlinks when receiveing files with the same name

Hi all, anyone with some ideas? I am missing something? Thanks. On 16/03/2016 16:30, Gionatan Danti wrote: Hi list, I would like to know if the following rsync's behavior can be changed/modified. I noticed that when rsync receive a file for which the local filesystem already has a symlinks

Deleted symlinks when receiveing files with the same name

Hi list, I would like to know if the following rsync's behavior can be changed/modified. I noticed that when rsync receive a file for which the local filesystem already has a symlinks with the same path/name, it _first_ delete the symlink, _then_ it start the transfer. I think

[Bug 10494] remove-source-files fails with symlinks

, I've added some code that should avoid this failure for symlinks and devices. -- You are receiving this mail because: You are the QA Contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org

feature request: rsync dereference symlinks on cmdline

dir of symlink maps. For eg openVZ names their containers with ID#s which isnt very condusive to careful handling/recognition: 100/ 101/ 102/ 103/ etc Id like to create a dir of symlinks, a map (I think this would work on the target too?) customer1 - ../production/100 customer2

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #8 from sylv...@ilm-informatique.fr --- To expand on the previous post : POSIX previously mandated that link() resolve the target (as FreeBSD does), but some systems (including Linux) did not. So in the last standard linkat() was added

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #9 from sylv...@ilm-informatique.fr --- Created attachment 10435 -- https://bugzilla.samba.org/attachment.cgi?id=10435action=edit configure.ac patch -- You are receiving this mail because: You are the QA Contact for the bug. --

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #10 from sylv...@ilm-informatique.fr --- Created attachment 10436 -- https://bugzilla.samba.org/attachment.cgi?id=10436action=edit syscall.c patch A #ifdef HAVE_LINKAT should probably be added -- You are receiving this mail because:

[Bug 10893] New: Allow option to sync symlinks last (or delayed)

https://bugzilla.samba.org/show_bug.cgi?id=10893 Bug ID: 10893 Summary: Allow option to sync symlinks last (or delayed) Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity

Re: Problem copying hard-linked symlinks

On Mon, Jun 16, 2014 at 10:51 AM, Chris Thompson c...@cam.ac.uk wrote: but rather than hardlinking the first symlink it hardlinks its *target* (or fails if the target doesn't exist [yet]). Yeah, that's what configure is testing for -- that link() doesn't work right with symlinks (it affects

Re: Problem copying hard-linked symlinks

: I'd imagine that your configure run was done on a filesystem that didn't support hardlinked symlinks, since the test program it runs is super simple and to the point. Super simple indeed (although it should probably unlink(FILENAME 2) as well as FILENAME, but that doesn't seem to help). Here

Re: Problem copying hard-linked symlinks

been working fine for quite a while. Yes - it contains /* Define to 1 if link() can hard-link symlinks. */ /* #undef CAN_HARDLINK_SYMLINK */ But this suggests something wrong with the configure script, as Solaris 10_x86 is perfectly capable of hardlinking symlinks. (This was rsync compiled from

Re: Problem copying hard-linked symlinks

On Sun, Jun 15, 2014 at 3:08 PM, Chris Thompson c...@cam.ac.uk wrote: But this suggests something wrong with the configure script, as Solaris 10_x86 is perfectly capable of hardlinking symlinks. I'd imagine that your configure run was done on a filesystem that didn't support hardlinked

Problem copying hard-linked symlinks

This has been niggling me for a while, but am only now getting around to reporting it. I have reproduced the problem with rsync 3.1.0 and nothing in the news file for 3.1.1pre2 looks hopeful... In some filing systems it is possible to have symlinks which are themselves hard linked, i.e. have

Re: Problem copying hard-linked symlinks

On Fri, Jun 13, 2014 at 12:29 PM, Chris Thompson c...@cam.ac.uk wrote: When copying these with -H, rsync gets more than a little confused: Your rsync must be configured without CAN_HARDLINK_SYMLINK being defined (see config.h), as the normal code has been working fine for quite a while.

[Bug 10629] New: rsync follows symlinks that point to same directory / endless loop

https://bugzilla.samba.org/show_bug.cgi?id=10629 Summary: rsync follows symlinks that point to same directory / endless loop Product: rsync Version: 3.1.1 Platform: All OS/Version: Linux Status: NEW

[Bug 10494] New: remove-source-files fails with symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10494 Summary: remove-source-files fails with symlinks Product: rsync Version: 3.1.0 Platform: x64 OS/Version: Linux Status: NEW Severity: major Priority: P5

[Bug 10238] --dry-run does not change directory, causes --link-dest failure on symlinks

Resolution||FIXED --- Comment #1 from Wayne Davison way...@samba.org 2013-11-25 17:19:55 UTC --- Both symlinks and devices had a bug where the finding of a link-dest item to use caused the itemize info to break when --dry-run was in effect. I changed the code to itemize against

[Bug 10238] New: --dry-run does not change directory, causes --link-dest failure on symlinks

https://bugzilla.samba.org/show_bug.cgi?id=10238 Summary: --dry-run does not change directory, causes --link-dest failure on symlinks Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW

[Bug 10220] symlinks are not counted as files in --stats

https://bugzilla.samba.org/show_bug.cgi?id=10220 --- Comment #2 from Ivan Dimitrov zlob...@gmail.com 2013-10-28 08:26:34 UTC --- Yes, I updated since then, but symlinks are not counted anywhere. Thus making a system that rely on `--dry-run --stats -v |grep transferred` would fail if only

[Bug 10220] symlinks are not counted as files in --stats

https://bugzilla.samba.org/show_bug.cgi?id=10220 --- Comment #3 from Wayne Davison way...@samba.org 2013-10-28 17:32:26 UTC --- As my paste shows, they are counted in the created files. They aren't counted in the updated regular files since they aren't regular files. -- Configure bugmail:

[Bug 10220] symlinks are not counted as files in --stats

https://bugzilla.samba.org/show_bug.cgi?id=10220 --- Comment #4 from Ivan Dimitrov zlob...@gmail.com 2013-10-28 20:26:44 UTC --- THANK YOU. Somehow I've omitted this. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: ---

[Bug 10220] symlinks are not counted as files in --stats

qualified to say regular files): Number of files: 7 (reg: 3, dir: 1, link: 3) Number of created files: 7 (reg: 3, dir: 1, link: 3) Number of deleted files: 0 Number of regular files transferred: 3 [...] Thus, symlinks will now be under the created-files stat. -- Configure bugmail: https

[Bug 10220] New: symlinks are not counted as files in --stats

https://bugzilla.samba.org/show_bug.cgi?id=10220 Summary: symlinks are not counted as files in --stats Product: rsync Version: 3.0.9 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P5

Re: Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

On Thu, Aug 29, 2013 at 3:53 PM, Daniel Freedman freed...@systems.cs.cornell.edu wrote: (1) Why is this the silent default? It's not silent -- it outputs errors that lets you know what happened and what it is doing (disabling deletes). (2) How do I achieve what I want, which is: Kevin

Re: Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

from the rsync run. I'd imagine that one of your unsafe symlinks is bogus, and you will be getting a pair of errors: symlink has no referent: /some/path IO error encountered -- skipping file deletion Great call! I've definitely always been getting these errors, and they are indeed from

Re: Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

in the destination, but not in the source. Be sure to check the errors from the rsync run. I'd imagine that one of your unsafe symlinks is bogus, and you will be getting a pair of errors: symlink has no referent: /some/path IO error encountered -- skipping file deletion Great call! I've

Re: Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

that one of your unsafe symlinks is bogus, and you will be getting a pair of errors: symlink has no referent: /some/path IO error encountered -- skipping file deletion Because a bogus dereferenced symlink can't be replaced with a file, it is left out of the transfer. This would cause the receiving side

Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

Hi, New to this list, but long-time (appreciative) user of rsync. Grateful for any help with my problem here... In particular, I've been having long-standing issues (just now getting around to trying to resolve them) when I use rsync with '--copy-unsafe-links' alongside the '--delete' parameter.

Re: Potential incompatibilities between '--delete' and --copy-unsafe-symlinks' ???

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How about if you use rsync's --link-dest instead of cp -al? Then no - --delete is needed as superfluous hard links aren't created in the first place. IOW, instead of /bin/cp -al /backup/daily.0 /backup/daily.1 drop the --delete and --delete-exculded

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #6 from Wayne Davison way...@samba.org 2013-08-08 16:02:13 UTC --- You should note that this bug is awaiting info that nobody has bothered to provide. Nothing more is going to be done until someone figures out what is needed. --

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #7 from awk sambabugzilla201...@awk.bz 2013-08-08 17:44:36 UTC --- Well, under FreeBSD linkat() will hardlink symlinks, i.e. instead of: link(source, target); use: linkat(AT_FDCWD, source, AT_FDCWD, target, 0); I patched my copy

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

https://bugzilla.samba.org/show_bug.cgi?id=8856 --- Comment #5 from awk sambabugzilla201...@awk.bz 2013-08-07 06:55:08 UTC --- Same behavior on: FreeBSD 9.x ZFS (and UFS) OmniOS (OpenSolaris) ZFS In fact it often just hangs outright after the No such file or directory error message. --

Re: delaying symlinks sync until the data it points to available

the completed files/symlinks into place very rapidly (make sure to use a relative --partial-dir, which is true by default). Or consider using the atomic-rsync script from the support dir which would allow you to do a normal --link-dest transfer into a new directory and (if setup with symlinks

delaying symlinks sync until the data it points to available

it is pointing to has arrived. This causes me all sorts of problem. Please don't advise me for exclude patterns since the symlinks can have different names (other than new). I just need that symlinks are written only after the data they are pointing is completed/done My illustration may

[Bug 8856] --hard-links does not handle hard-linked symlinks correctly on FreeBSD

from Wayne Davison way...@samba.org 2013-05-27 00:18:04 UTC --- Look at the test in configure.ac where it checks if link() can hard-link symlinks and see what needs to change for FreeBSD. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail

Target: following file symlinks?

files again. I tried -l (which is in -a, anyway, but I tried it explicitely, just for the case), -L and -K, but still I got the same behaviour. Is there a way to make rsync follow the symlinks at the target machine? Thank you very much in advance! Best regards, Yuriy -- Please use reply

Re: Target: following file symlinks?

for the case), -L and -K, but still I got the same behaviour. Is there a way to make rsync follow the symlinks at the target machine? Thank you very much in advance! Best regards, Yuriy - -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Kevin Korb

Re: Target: following file symlinks?

handle symlinks. There is absolutely no way they will start messing up with stuff like lvm just because of this one thing. So, my question remains: can rsync somehow handle symlinks at the target machine, or should I use some other tools? On 07/20/2012 07:20 PM, Kevin Korb wrote: -BEGIN PGP

Re: Target: following file symlinks?

On Fri, 20 Jul 2012, Yuriy Davygora wrote: So, my question remains: can rsync somehow handle symlinks at the target machine, or should I use some other tools? A little Googling and/or RTFM would be appropriate, would it not? Check the man page on: --copy-dirlinks Or Google

Re: Target: following file symlinks?

Seen that, tried that, did not work, it deleted all my links and started downloading the files again. Apparently, judging by the title of this option it only follows directory symlinks, I have file symlinks. A little reading of my exact question might be appropriate, would it not? Anyway, I

  1   2   3   4   >