[PATCH] Make progress output show done instead of to-chk.
In incremental recursion mode, the number of files to check can increase (when
new file-list chunks are built) as well as decrease, which I found confusing to
watch. This patch makes the progress line show the number of files done
(which increases monotonically) instead.
I did notice that the last progress line shows done=N-1/N instead of
done=N/N; that is perhaps unsettling but not really wrong.
---
I'm sending this patch to the main rsync list rather than
[EMAIL PROTECTED] because others might want to express
opinions on it.
Matt
progress.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/progress.c b/progress.c
index 25be374..7309a5d 100644
--- a/progress.c
+++ b/progress.c
@@ -72,9 +72,9 @@ static void rprint_progress(OFF_T ofs, OFF_T size, struct
timeval *now,
if (is_last) {
int len = snprintf(eol, sizeof eol,
-(xfr#%d, to-chk=%d/%d)\n,
+(xfr#%d, done=%d/%d)\n,
stats.xferred_files,
- stats.num_files - current_file_index - 1,
+ current_file_index,
stats.num_files);
if (INFO_GTE(PROGRESS, 2)) {
static int last_len = 0;
--
1.6.0.2.593.g91df
--
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
Question regarding --delete-during/after and backup file cases
A good while ago I asked about difference between --delete-during/delay and --delete-after, when per-directory files are updated (all is perfectly clear for me here), but during the discussion there was a hint made by Wayne, that the outcome can differ in more situations: It is useful for things such as --delay-updates --delete-delay (to have all updates happen more rapidly at the end), and the option avoids an extra dir-scan delete pass in such a case. And for folks that don't have per-dir filter files being updated, it works the same as --delete-after (if we disregard certain backup-file cases where the suffix is not excluded), just more optimally. If I understand it correctly - those backup-file cases mean -b option and - accidental or deliberate - override of the protect rule added implicitly by rsync (as explained in the man page). But if this rule is overriden (effectivly allowing deletion of backuped files), then assuming no per-dir rules are changed, the outcome will be the same regardless if we use --delete-during + --delete-delay or --delete-after. So there must be something I missed or misunderstood. Could someone provide me a simple example of such backup-file case ? -- 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
Re: NTFS to NTFS backup
On Wed, 2008-10-22 at 12:49 +0100, Simao M wrote: *deleting work/software/prc/dcpcrypt2/Hashes/DCPtiger.pas f+ software/prc/dcpcrypt2/Hashes/DCPtiger.pas rsync --stats --modify-window=1 --size-only --dry-run -aruvv --progress --delete /media/sda1/Documents\ and\ Settings/simao/ /media/sda1/work/ /media/truecrypt6/backup/ Ah. Your source argument /media/sda1/work/ with a trailing slash, which puts that directory at the root of the rsync file list, does not match the existing data in the work/ subdirectory of the destination. How you should fix this depends on where you want the source files to go. Let's take the source file /media/sda1/work/software/prc/dcpcrypt2/Hashes/DCPtiger.pas as an example. If you want it to go to /media/truecrypt6/backup/work/software/prc/dcpcrypt2/Hashes/DCPtiger.pas , then either change the source argument to /media/sda1/work (without the trailing slash) or change the destination to /media/truecrypt6/backup/work/ . On the other hand, if you want the file to go to /media/truecrypt6/backup/software/prc/dcpcrypt2/Hashes/DCPtiger.pas , then leave the rsync command as is but run a manual mv /media/truecrypt6/backup/work/* /media/truecrypt6/backup/ to avoid recopying all the files. Matt -- 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
DO NOT REPLY [Bug 5811] rsync error: error allocating core memory buffers (code 22) at io.c(635)
https://bugzilla.samba.org/show_bug.cgi?id=5811 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #4 from [EMAIL PROTECTED] 2008-10-22 13:12 CST --- Hello, I think i found the problem i faced with. rsync command is successful on an english locale Mac os X using : --iconv=UTF8-MAC,ISO-8859-15 The problem came from the fact that the Mac os X used for that bug report is in french, so i had to use : --iconv=ISO-8859-15,ISO-8859-15 and it is ok now. Regards. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- 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
Re: Rsync 3.0.3 with patches on OS X 10.4.11 fails to copy ACLs
Check that ACL's are enabled on the destination volume. Details on how to do this are available from the following URL : http://connect.homeunix.com/lbackup/doku.php?id=access_control_lists Hope this helps. I am using rsync 3.0.3 to copy a remote RAID volume on one Xserve to the local RAID volume on an other Xserve. Both Xserves are running OS X Server 10.4.11. I have compiled rsync 3.0.3 on both machines and patched it following Mike Bombich's instructions at http://www.bombich.com/mactips/rsync.html After some struggles, and with invaluable help from the list, I how have an rsync script running to completion but it generates log errors, I think for every file, and fails to copy ACLS, even though the ACL flag for Macs is set as shown in the OPTS variable in my backup script: OPTS=(-aAX --delete --archive --rsync-path=/usr/local/bin/rsync --protect-args --fileflags --force-change) Some sample error log entries are: rsync: set_acl: sys_acl_set_file(SN3201128/.Share Your Images.url.g4bMCP, ACL_TYPE_EXTENDED): Operation not supported (45) rsync: set_acl: sys_acl_set_file(SN3201128/.Warez Home.url.WxglUO, ACL_TYPE_EXTENDED): Operation not supported (45) rsync: set_acl: sys_acl_set_file(SN3201128/ Steinberg_Nuendo_v3.2.0.1128/.Steinberg.Nuendo.ex e.i2w172, ACL_TYPE_EXTENDED): Operation not supported (45) I saw similar errors when I was running Carbon Copy Cloner on the same volumes, which also uses rsync 3.0.3 and was informed that in some cases these are only log artifacts and not real errors. In this case, however, I have checked and ACLs do not seem to be preserved in the copies. I know ACL support for Mac has been problematical until recently, but can anyone suggest troubleshooting steps I might take to try to fix the ACL problem. I an certainly supply the entire rsync script and entire log contents if that will help. Thank you, --Carney Mimms -- 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 -- 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
