Hey!
Given all the attributed for rsync...
Is there an attribute or approach to allow/force rsync to redo a "complete" xfer of files..?
I'm sure there is but I must be missing it..
thanks..
On Sat, 10 Feb 2018 12:16:47 -0500 bruce badouglas@gmail.com wrote:
Is there an attribute or approach to allow/force rsync to redo a "complete" xfer of files..?
I'm not aware of a way, and it makes sense. If the identical file is already there, why would rsync spend the resources to replace it?
If you want to re-transfer everything, just rm -rf the files and directories on the destination. Be careful that you are definitely in the right directory, as this will wipe out everything below the directory where you run the command.
If you just want to change owner:group, permissions or attributes use the chown, chmod, or chcon programs on the destination. This can be recursive with the -R option.
Date: Saturday, February 10, 2018 12:16:47 -0500 From: bruce badouglas@gmail.com
Given all the attributed for rsync...
Is there an attribute or approach to allow/force rsync to redo a "complete" xfer of files..?
I'm sure there is but I must be missing it..
The issue(s) that you seem to be encountering, as described in your earlier message, aren't due to limitations in rsync. Rather that you are trying to transfer files that your "basic user" doesn't have control over (on either the source or target machine). If you did this as root you would get rather closer to your goal.
From a security and system stability perspective, there is no way
that any system should let a "basic user" do what you are trying to accomplish.
Hey...
Got it.. or think I do.. It appears the -I --ignore-times attribute will essentially force a redo of any/all files in the rsync...
I'm interested in examining the list as the files are transferred..
thanks
On Sat, Feb 10, 2018 at 12:48 PM, Richard lists-fedora@listmail.innovate.net wrote:
Date: Saturday, February 10, 2018 12:16:47 -0500 From: bruce badouglas@gmail.com
Given all the attributed for rsync...
Is there an attribute or approach to allow/force rsync to redo a "complete" xfer of files..?
I'm sure there is but I must be missing it..
The issue(s) that you seem to be encountering, as described in your earlier message, aren't due to limitations in rsync. Rather that you are trying to transfer files that your "basic user" doesn't have control over (on either the source or target machine). If you did this as root you would get rather closer to your goal.
From a security and system stability perspective, there is no way
that any system should let a "basic user" do what you are trying to accomplish.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On 02/10/2018 12:31 PM, bruce wrote:
Hey...
Got it.. or think I do.. It appears the -I --ignore-times attribute will essentially force a redo of any/all files in the rsync...
Actually it will do the opposite. With the "-I" flag, rsync will ignore differences in modification times as a criterion for deciding whether the source and destination files are different, leaving just a comparison of file sizes as the determining factor.
On 10Feb2018 20:50, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 02/10/2018 12:31 PM, bruce wrote:
Hey...
Got it.. or think I do.. It appears the -I --ignore-times attribute will essentially force a redo of any/all files in the rsync...
Actually it will do the opposite. With the "-I" flag, rsync will ignore differences in modification times as a criterion for deciding whether the source and destination files are different, leaving just a comparison of file sizes as the determining factor.
No, that would be nuts. From the manual:
-I, --ignore-times Normally rsync will skip any files that are already the same size and have the same modification timestamp. This option turns off this "quick check" behavior, causing all files to be updated.
It does jyst what bruce thought it did.
For super paranoia bruce would add the -W option, and the -i or --progress options to see things happening.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)
On 02/10/2018 09:16 PM, Cameron Simpson wrote:
On 10Feb2018 20:50, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 02/10/2018 12:31 PM, bruce wrote:
Hey...
Got it.. or think I do.. It appears the -I --ignore-times attribute will essentially force a redo of any/all files in the rsync...
Actually it will do the opposite. With the "-I" flag, rsync will ignore differences in modification times as a criterion for deciding whether the source and destination files are different, leaving just a comparison of file sizes as the determining factor.
No, that would be nuts. From the manual:
-I, --ignore-times Normally rsync will skip any files that are already the same size and have the same modification timestamp. This option turns off this "quick check" behavior, causing all files to be updated.
It does jyst what bruce thought it did.
Not quite, it will still check the contents of the file and if they are the same, it won't transfer it.
On 11Feb2018 16:40, Samuel Sieb samuel@sieb.net wrote:
On 02/10/2018 09:16 PM, Cameron Simpson wrote:
On 10Feb2018 20:50, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 02/10/2018 12:31 PM, bruce wrote:
Got it.. or think I do.. It appears the -I --ignore-times attribute will essentially force a redo of any/all files in the rsync...
Actually it will do the opposite. With the "-I" flag, rsync will ignore differences in modification times as a criterion for deciding whether the source and destination files are different, leaving just a comparison of file sizes as the determining factor.
No, that would be nuts. From the manual:
-I, --ignore-times Normally rsync will skip any files that are already the same size and have the same modification timestamp. This option turns off this "quick check" behavior, causing all files to be updated.
It does jyst what bruce thought it did.
Not quite, it will still check the contents of the file and if they are the same, it won't transfer it.
That is true. -W should force a full transfer:
-W, --whole-file With this option rsync’s delta-transfer algorithm is not used and the whole file is sent as-is instead. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (especially when the "disk" is actually a networked filesystem). This is the default when both the source and des‐ tination are specified as local paths, but only if no batch-writing option is in effect.
I confess that by the time I want that I tend to just use "tar cf - ... | ssh over-there tar xf -"; tar and cp and scp tend to outperform rsync if there aren't network bottlenecks. Rsync's great strength is incremental update.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)