Hello,
Many years ago, FC4 days, the following command run as a cron job would result in a nice summary email as follows
/usr/bin/rsync -a --no-whole-file --delete /music /thecus-music/
---------------------------------------------- building file list ... done
sent 351583 bytes received 20 bytes 11527.97 bytes/sec total size is 62922572805 speedup is 178959.15 ----------------------------------------------
or
---------------------------------------------- building file list ... done Cat Stevens/The Very Best Of/23 - Peace Train.mp3 Cat Stevens/The Very Best Of/24 - If You Want To Sing Out, Sing Out.mp3
sent 378288 bytes received 27700 bytes 11436.28 bytes/sec total size is 62264729571 speedup is 153365.94 ----------------------------------------------
The same command under CentOS6 is silent, how do I get the nice summary email abain?
On 2014-12-14, Niamh Holding niamh@fullbore.co.uk wrote:
Many years ago, FC4 days, the following command run as a cron job would result in a nice summary email as follows
/usr/bin/rsync -a --no-whole-file --delete /music /thecus-music/
building file list ... done
sent 351583 bytes received 20 bytes 11527.97 bytes/sec total size is 62922572805 speedup is 178959.15
The same command under CentOS6 is silent, how do I get the nice summary email abain?
That must have been a very long time ago, as rsync has been silent for as long as I can remember (even back to CentOS 5 and possibly even 4).
Anyway, you want some combination of the -v and --progress switches. Try each separately, and both together, and see which you like best.
--keith
Hello Keith,
Sunday, December 14, 2014, 6:31:20 PM, you wrote:
KK> Anyway, you want some combination of the -v and --progress switches. KK> Try each separately, and both together, and see which you like best.
Neither!
Both switches list the folders being checked even if the contents are unchanged
On Dec 14, 2014 11:01 AM, "Niamh Holding" niamh@fullbore.co.uk wrote:
Hello Keith,
Sunday, December 14, 2014, 6:31:20 PM, you wrote:
KK> Anyway, you want some combination of the -v and --progress switches. KK> Try each separately, and both together, and see which you like best.
Neither!
Both switches list the folders being checked even if the contents are unchanged
Folders should only be listed if timestamps or permissions are different.
-- Les Mikesell Les@gmail.com
rsync -h ... -i, --itemize-changes output a change-summary for all updates ...
K --
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Hello Kahlil,
Sunday, December 14, 2014, 8:54:45 PM, you wrote:
KH> -i, --itemize-changes output a change-summary for all updates
Lists every file here
Hello Les,
Sunday, December 14, 2014, 7:18:09 PM, you wrote:
LM> Folders should only be listed if timestamps or permissions are different.
Further experimentation shows this to be the case IF the destination is another local drive.
Unfortunately the required destination is a CIFS share, which might change things.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-15 14:43, Niamh Holding wrote:
LM> Folders should only be listed if timestamps or permissions are LM> different.
Further experimentation shows this to be the case IF the destination is another local drive.
Unfortunately the required destination is a CIFS share, which might change things.
Sounds like it might be differences in precision of the timestamp. Check out the `--modify-window` option.
- -- AF24 6DE9 D1DF DFB8 3A74 A7AC F457 B7A3 5DF1 4240
Hello Elias,
Monday, December 15, 2014, 4:13:20 PM, you wrote:
EP> Sounds like it might be differences in precision of the timestamp.
Could be, thoght the NAS box has the sending system as it's NTP server so their times should be in sync.
EP> Check out the `--modify-window` option.
Doesn't seem to stop all the folders being listed even though nothing is transferred.
/usr/bin/rsync -av --modify-window=20 --no-whole-file --delete /music /NSA320-music/ . . .
music/Yes/ music/Yes/Close to the Edge/ music/Yes/Fragile/ music/Yes/Tales From Topographic Oceans/ music/Yes/Yes Album/ music/Yes/Yessongs/ music/Yngwie Malmsteen, Joe Satriani & Steve Vai/ music/Yngwie Malmsteen, Joe Satriani & Steve Vai/G3- Rockin' in the Free World/ music/ZZ Top/ music/ZZ Top/Live From Texas/ music/ZZ Top/The Best of ZZ Top/ music/ZZ Top/ZZ Top Greatest Hits/ music/lost+found/
When you use --itemize-changes, does it indicate that the timestamps of the directories have changed?
K
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Hello Kahlil,
Monday, December 15, 2014, 11:25:35 PM, you wrote:
KH> When you use --itemize-changes, does it indicate that the timestamps of the KH> directories have changed?
Not uless the sequence of dots and letters before the folder name indicates that
On Tue, Dec 16, 2014 at 7:39 PM, Niamh Holding niamh@fullbore.co.uk wrote:
KH> When you use --itemize-changes, does it indicate that the timestamps of the KH> directories have changed?
Not uless the sequence of dots and letters before the folder name indicates that
-- Best regards, Niamh mailto:niamh@fullbore.co.uk
Indeed: the sequence of dots and letters before the name indicates why rsync wants to update a file.
From the '--itemize-changes' entry in the rsync man page:
"A t means the modification time is different and is being updated to the sender’s value"
"A p means the permissions are different and are being updated to the sender’s value"
See the man page for the meaning of other symbols.
Kal
Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd
Suite 1416 401 Docklands Drive Docklands VIC 3008 Australia
"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925
Hello Kahlil,
Tuesday, December 16, 2014, 11:19:11 PM, you wrote:
KH> Indeed: the sequence of dots and letters before the name indicates why KH> rsync wants to update a file.
Ah, not time but owner and group are different, and not being changed on the NAS.
Is this a CIFS "thing"?
On Wed, Dec 17, 2014 at 3:21 AM, Niamh Holding niamh@fullbore.co.uk wrote:
KH> Indeed: the sequence of dots and letters before the name indicates why KH> rsync wants to update a file.
Ah, not time but owner and group are different, and not being changed on the NAS.
Is this a CIFS "thing"?
CIFS mounts are normally done as one user, with user-level credentials. If this user is the owner of all the files and directories on the source side, they should match - but otherwise an attempt to change ownership will fail. Samba offers a user mapping option that might help but if the NAS offers nfs (or ssh and rsync), that might be a better approach.
Hello Les,
Wednesday, December 17, 2014, 3:54:36 PM, you wrote:
LM> if the NAS offers nfs
It does, but I'm waiting for an answer from Zyxel as to why the data rate is limited to about 3.5Mb/s as opposed to 60-70Mb/s to a CIFS share
On Mon, Dec 15, 2014 at 10:41 AM, Niamh Holding niamh@fullbore.co.uk wrote:
Hello Elias,
Monday, December 15, 2014, 4:13:20 PM, you wrote:
EP> Sounds like it might be differences in precision of the timestamp.
Could be, thoght the NAS box has the sending system as it's NTP server so their times should be in sync.
EP> Check out the `--modify-window` option.
Doesn't seem to stop all the folders being listed even though nothing is transferred.
/usr/bin/rsync -av --modify-window=20 --no-whole-file --delete /music /NSA320-music/
What happens if you use --modify-window=3601 to allow up to an hour of difference? Your NAS may have windows-like behavior in terms of storing timestamps in local time and fudging them for DST.
Hello Les,
Tuesday, December 16, 2014, 4:09:43 PM, you wrote:
LM> What happens if you use --modify-window=3601 to allow up to an hour of LM> difference? Your NAS may have windows-like behavior in terms of LM> storing timestamps in local time and fudging them for DST.
Exactly the same :(
--stats comes close, but doesn't list the files updated or deleted.
On Tue, Dec 16, 2014 at 12:56 PM, Niamh Holding niamh@fullbore.co.uk wrote:
Hello Les,
Tuesday, December 16, 2014, 4:09:43 PM, you wrote:
LM> What happens if you use --modify-window=3601 to allow up to an hour of LM> difference? Your NAS may have windows-like behavior in terms of LM> storing timestamps in local time and fudging them for DST.
Exactly the same :(
What about the ownership/permissions? There must be something in the attributes that appears different between the source/destination that makes rsync want to attempt to fix it - and fail, since you still see it the next time. Not sure why this would be different between files and directories, though. If you can find the difference you might work around it by unbundling the -a option and omitting trying to sync whatever attribute that isn't working.
On Mon, 15 Dec 2014 at 11:41 -0000, Niamh Holding wrote:
EP> Sounds like it might be differences in precision of the timestamp.
Could be, thoght the NAS box has the sending system as it's NTP server so their times should be in sync.
EP> Check out the `--modify-window` option.
Doesn't seem to stop all the folders being listed even though nothing is transferred.
/usr/bin/rsync -av --modify-window=20 --no-whole-file --delete /music /NSA320-music/ . . .
music/Yes/ music/Yes/Close to the Edge/ music/Yes/Fragile/ music/Yes/Tales From Topographic Oceans/ music/Yes/Yes Album/ music/Yes/Yessongs/ music/Yngwie Malmsteen, Joe Satriani & Steve Vai/ music/Yngwie Malmsteen, Joe Satriani & Steve Vai/G3- Rockin' in the Free World/ music/ZZ Top/ music/ZZ Top/Live From Texas/ music/ZZ Top/The Best of ZZ Top/ music/ZZ Top/ZZ Top Greatest Hits/ music/lost+found/
If you don't want the directories themselves checked you may want the -O (--omit-dir-times) option.
If this is a CIFS or other DOSish filesystem you may also need --no-o --no-p and/or --no-g to ignore other file attributes.
Stuart
Hello Stuart,
Tuesday, December 16, 2014, 9:33:29 PM, you wrote:
SB> If this is a CIFS or other DOSish filesystem you may also need --no-o SB> --no-p and/or --no-g to ignore other file attributes.
Looks like this may be the case to solve that problem.
Hello Keith,
Sunday, December 14, 2014, 6:31:20 PM, you wrote:
KK> That must have been a very long time ago, as rsync has been silent for KK> as long as I can remember (even back to CentOS 5 and possibly even 4).
I think we're going back to rsync 2.6.x for this very useful summary.