Windows and default --modify-window=0
Uhm... rsync developers: what do you think about changing the default modify-window in the Cygwin platform? It seems to me that many problems people have are just because of the granularity of timestamp. Maybe changing the default could be the best choice. That would be documented in the man and in my release announcement on cygwni-annouce, of course. Just an idea, maybe it's bad 0=) -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Stats
Title: Message Hello - Can someone please clarify the meaning of these stats. This is the rsync'ing of one file remotely over a wan. Total file size: 383219712 bytesTotal transferred file size: 383219712 bytesLiteral data: 3143680 bytesMatched data: 380076032 bytes The total file size is definitely correct, but what I don't understand is the transfered size. Is rsync reporting that roughly 380mb matches? It would seem like it to me. But is so, why did it transfer the entire file? Or did it? I actually only took 8 minutes which seemed very short (over a slow WAN) Thanks - Max
exclude pattern
Yes, I know that's a newbie question. I want to rsync a tree SERVER1:/src/repository to SERVER2:/otherlocation/repository with one rsync command. Under repository are the directories foo and foo/bar/foo Now I want to rsync foo/bar/foo but not foo. I want to use the --exclude-from switch (to be able to specify more exclude patterns). Could you please tell me, what the command and pattern has to look like? -- Mat -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Proper --exclude= syntax? -- thanks!
--- jw schultz [EMAIL PROTECTED] wrote: On Wed, Jan 08, 2003 at 02:15:13PM -0800, Dan Kressin wrote: I'm currently syncing the home directories on two boxes with the syntax: dest-host# rsync -av -e ssh --delete --progress source-host:/home/ /home/ That's working well. Now I want to exclude /home/httpd/* from the process. (I don't want web changes on one box to affect the other box.) Which of the following is the best/correct one to use? [snip] None of the above. --exclude=/httpd/ Patterns are relative to the src/dest paths. [snip] Thanks to both JW Schultz and Max B. who suggested the same solution and helpfully pointed out why my guesses were wrong. -Dan __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 01:02:29PM +0100, Lapo Luchini wrote: Uhm... rsync developers: what do you think about changing the default modify-window in the Cygwin platform? It seems to me that many problems people have are just because of the granularity of timestamp. Maybe changing the default could be the best choice. That would be documented in the man and in my release announcement on cygwni-annouce, of course. Just an idea, maybe it's bad 0=) As I understand it, --modify-window=2 is needed whenever you're copying between a Windows filesystem (maybe only specific types, does anybody know??) and a Unix filesystem. Just because you're running on Cygwin, that doesn't necessarily mean you're doing that although the risk of a file modification time legitimately being off by a few seconds is pretty low in the cases where it isn't really needed. (Conversely, on Linux you may be accessing a Windows filesystem directly but I realize you're not talking about that situation). The main problem is that if Cygwin always added the --modify-window=2 option to parameters it passes to the remote side it would fail if it were talking to a release of rsync that is too old to recognize the option. If it could be done on the cygwin side only, without passing the parameter to the remote side, it might not be so bad. I guess that would mean it would work only when receiving files from a Unix system and not when sending to them. The surprise factor on that may be too much to make it worthwhile. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
Dave Dykstra wrote: it would fail if it were talking to a release of rsync that is too old to recognize the option[...]. The surprise factor on that may be too much to make it worthwhile. I agree. I didn't think about that. But, given the resilience to upgrade many people have, you sure are right. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Stats
On Thu, Jan 09, 2003 at 07:48:50AM -0600, Max Kipness II wrote: Total file size: 383219712 bytes Total transferred file size: 383219712 bytes Literal data: 3143680 bytes Matched data: 380076032 bytes The total file size is definitely correct, but what I don't understand is the transfered size. Is rsync reporting that roughly 380mb matches? It would seem like it to me. But is so, why did it transfer the entire file? You're thinking of the word transfer in the wrong sense here. Rsync's transferred file size is the total of all file sizes that needed to be updated. However, it doesn't mean that those bytes were sent literally over the wire. That stat is taken care of in the next two lines, which tells you how much data was actually communicated literally (3143680 bytes) and how much data was communicated via matched blocks (380076032 byes). Also, in a set of files where some matched and some didn't, the total file size would have included the entire set of files (including those that were up-to-date). In a set of one, needs-to-be-updated file, the total size will always match the transferred size. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Help with CVS related include pattern
I'm trying to use rsync to make a local copy of only a subset of a directory tree: all directories, and all files within CVS/ directories, but nothing else. I thought this might work: rsync -av --include '*/' --include 'CVS/*' --exclude '*' src src_cvs It does recursively copy all directories (including CVS directories), but it doesn't copy the files within the CVS directories. What am I missing? I'm using rsync 2.5.5, and I see the behavior on both Solaris and Cygwin. Thanks! -David -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 05:52:43PM +0100, Lapo Luchini wrote: Dave Dykstra wrote: it would fail if it were talking to a release of rsync that is too old to recognize the option[...]. The surprise factor on that may be too much to make it worthwhile. I agree. I didn't think about that. But, given the resilience to upgrade many people have, you sure are right. It could perhaps key off the remote protocol version number. The version number is not as a rule incremented when new options are added, but it could check for whatever version the protocol was incremented to after the option was added, and only add the option then. No, wait, that won't work because the protocol version number isn't exchanged until after the option parameters are passed. The only way to do it would be to modify the protocol to include the info instead of passing a parameter. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 11:32:30AM -0600, Dave Dykstra wrote: The only way to do it would be to modify the protocol to include the info instead of passing a parameter. I realize this may sound like heresy, but would it not be worthwhile in terms of code simplification/robustness to break compatibility with older (protocol) versions of rsync at some point, _before_ rewriting the whole application based on librsync? Just a thought. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: exclude pattern
-- wrote: Yes, I know that's a newbie question. I want to rsync a tree SERVER1:/src/repository to SERVER2:/otherlocation/repository with one rsync command. Under repository are the directories foo and foo/bar/foo Now I want to rsync foo/bar/foo but not foo. I want to use the --exclude-from switch (to be able to specify more exclude patterns). Could you please tell me, what the command and pattern has to look like? + /foo/bar/ - /foo/* + /foo/bar/foo/ - /foo/bar/* Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
child exit code rsync bug patch finally submitted
I am preparing for making 2.5.6pre1 today and decided to submit David
Staples patch with a little rework. Here's the version I submitted.
- Dave Dykstra
--- main.c~ Thu Aug 1 15:46:59 2002
+++ main.c Thu Jan 9 12:43:55 2003
@@ -26,6 +26,16 @@
extern struct stats stats;
extern int verbose;
+/* there's probably never more than at most 2 outstanding child processes,
+ * but set it higher just in case.
+ */
+#define MAXCHILDPROCS 5
+
+struct pid_status {
+ pid_t pid;
+ int status;
+} pid_stat_table[MAXCHILDPROCS];
+
static void show_malloc_stats(void);
/
@@ -33,11 +43,27 @@
/
void wait_process(pid_t pid, int *status)
{
- while (waitpid(pid, status, WNOHANG) == 0) {
+ pid_t waited_pid;
+ int cnt;
+
+ while ((waited_pid = waitpid(pid, status, WNOHANG)) == 0) {
msleep(20);
io_flush();
}
+ if ((waited_pid == -1) (errno == ECHILD)) {
+ /* status of requested child no longer available.
+* check to see if it was processed by the sigchld_handler.
+*/
+ for (cnt = 0; cnt MAXCHILDPROCS; cnt++) {
+ if (pid == pid_stat_table[cnt].pid) {
+ *status = pid_stat_table[cnt].status;
+ pid_stat_table[cnt].pid = 0;
+ break;
+ }
+ }
+ }
+
/* TODO: If the child exited on a signal, then log an
* appropriate error message. Perhaps we should also accept a
* message describing the purpose of the child. Also indicate
@@ -848,7 +874,24 @@
static RETSIGTYPE sigchld_handler(int UNUSED(val)) {
#ifdef WNOHANG
- while (waitpid(-1, NULL, WNOHANG) 0) ;
+ int cnt, status;
+ pid_t pid;
+ /* An empty waitpid() loop was put here by Tridge and we could never
+* get him to explain why he put it in, so rather than taking it
+* out we're instead saving the child exit statuses for later use.
+* The waitpid() loop presumably eliminates all possibility of leaving
+* zombie children, maybe that's why he did it.
+*/
+ while ((pid = waitpid(-1, status, WNOHANG)) 0) {
+/* save the child's exit status */
+for (cnt = 0; cnt MAXCHILDPROCS; cnt++) {
+ if (pid_stat_table[cnt].pid == 0) {
+ pid_stat_table[cnt].pid = pid;
+ pid_stat_table[cnt].status = status;
+ break;
+ }
+}
+ }
#endif
}
On Tue, Sep 03, 2002 at 06:29:03PM -0700, jw schultz wrote:
Subject: Re: [patch] for rsync
On Tue, Sep 03, 2002 at 05:00:02PM -0700, [EMAIL PROTECTED] wrote:
JW,
I pushed everything to a LINUX box and did the diff again this time with the
-bur option.
It does look significantly different. I think I've got below what you are
looking for, so I am
resending it to [EMAIL PROTECTED]
I'm including two additional people as they have asked for the patch information
as well.
The diff was performed on main.c (2.5.5 version from rsync.samba.org). I hope
everyone
knows that I'm my purpose in providing this information, is so that everyone can
critique
my code (to make it better) and we can eliminate this problem for everyone.
Dave
Thank you Dave. I've been abusing/educating him a bit
offline so be nice everybody. He has not only diagnosed the
bug independantly but has come up with a direction to go
toward a permanent solution.
Aside from my dislike of a fixed size array
my comments are below.
-
--- main.c.orig Tue Sep 3 16:38:23 2002
+++ main.c Tue Sep 3 16:41:08 2002
@@ -27,6 +27,11 @@
extern int verbose;
+struct pid_status {
+pid_t pid;
+int status;
+ } pid_stat_table[10];
The use of a literal here is bad news.
Should be a #define CHILD_TABLE_SIZE or whatever.
Then macro can be used in the loops.
Question. Is 10 a good size? Should it be more?
I've not dug into the child spawning of rsync.
+
static void show_malloc_stats(void);
/
@@ -34,9 +39,27 @@
/
void wait_process(pid_t pid, int *status)
{
-while (waitpid(pid, status, WNOHANG) == 0) {
+pid_t waited_pid;
+int cnt;
+
+while ( 1 ) {
+ waited_pid = waitpid(pid, status, WNOHANG);
+ if ( waited_pid == 0 ) {
msleep(20);
io_flush();
+
Re: Help with CVS related include pattern
On Thu, Jan 09, 2003 at 12:30:30PM -0500, David Eisner wrote: I thought this might work: rsync -av --include '*/' --include 'CVS/*' --exclude '*' src src_cvs If things were working correctly, yes, that would indeed work. The problem is that the 'CVS/*' item has an interior slash, and rsync currently interprets this as being anchored (i.e. as '/CVS/*'). Use this command to work around the problem: rsync -av --include '*/' --include '**/CVS/*' --exclude '*' src src_cvs This should work in your case even though (a) **/... doesn't match in the root of the transfer (which won't affect you unless you change the src to src/), and (b) the trailing * gets treated like ** (which should have no ill effects when transferring CVS dirs since they don't tend to have subdirs). A previous patch of mine that replaces the matching code with something that properly interprets ** and * in the same item and also properly floats an unanchored match term with an interior slash would have worked as expected with your original command. I hope to get this fix into rsync eventually, but we've been in a let's release soon mode for quite a while, and I haven't wanted to commit such a big change in the current release cycle. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 10:36:33AM -0600, Dave Dykstra wrote: On Thu, Jan 09, 2003 at 01:02:29PM +0100, Lapo Luchini wrote: Uhm... rsync developers: what do you think about changing the default modify-window in the Cygwin platform? It seems to me that many problems people have are just because of the granularity of timestamp. Maybe changing the default could be the best choice. That would be documented in the man and in my release announcement on cygwni-annouce, of course. Just an idea, maybe it's bad 0=) As I understand it, --modify-window=2 is needed whenever you're copying between a Windows filesystem (maybe only specific types, does anybody know??) and a Unix filesystem. Just because you're running on Cygwin, that doesn't necessarily mean you're doing that although the risk of a file modification time legitimately being off by a few seconds is pretty low in the cases where it isn't really needed. (Conversely, on Linux you may be accessing a Windows filesystem directly but I realize you're not talking about that situation). The main problem is that if Cygwin always added the --modify-window=2 option to parameters it passes to the remote side it would fail if it were talking to a release of rsync that is too old to recognize the option. If it could be done on the cygwin side only, without passing the parameter to the remote side, it might not be so bad. I guess that would mean it would work only when receiving files from a Unix system and not when sending to them. The surprise factor on that may be too much to make it worthwhile. The 2 second timestamp resolution only applies to some windows filesystems. I think NTFS has timestamp resolution in the milliseconds (unlrelated to precision). It should only become an issue when the windows filesystem is the destination. The timestamp comparisons are actually done on the destination. Since you only need the --modify-window for a *ix-windows transfer the it might be possible to HACK it on the cygwin end. Further examination shows that it is already hacked in options.c for win32: | #ifdef _WIN32 | int modify_window=2; | #else | int modify_window=0; | #endif perhaps something just needs to be added to the #ifdef. PS. If i'm reading things correctly you only need a modify_window of 1 since it is a = test. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Help With Restoring
To Mike and the Rsync community, This is by far the greatest utility I have ever used for backing up an entire system. My Redhat server got botched during an upgrade. I reformatted my partitions and installed a minimal system. Rsync'ed the entire / directory back and the server came back to life. databases, websites, hardware configs, everything! I'm back in business. As a Linux newbie, not a luser, I really appreciate the response I received from Mike and others. As the days pass and my skills refine, I will offer back as much support as I can. I guess you can say another BillyBorg saved :) Thanks Again! Mark rsync --delete --stats --compress --recursive --times --perms --links --rsh=/usr/bin/ssh --exclude tmp/ --exclude dev/ --exclude proc/ --exclude backups/ --delete-excluded --backup --backup-dir=/backup2/BACKED_UP_SERVER_FQDN/$DAY -a /* CENTRAL_SERVER_IP:/backup2/BACKED_UP_SERVER_FQDN/current echo Daily backup ran on `date` /var/log/backup.log Notice that if you have any dotfiles in / (that is, flies that begin with a .), this will not copy them, but normally you wouldn't have dotfiles in / so it shouldn't matter. Might want to start using / instead of /* from now on though, just for good form. Thanks fot the tip :) This has been working fine and I've even been able to restore files using scp from time to time. now I'm faced with a bare metal recovery cause of a botched upgrade from Redhat 7.1 to 8.0 that failed half way through. This machine was still accessible via console and ssh (putty). I signed in via ssh and ran... # cd / # scp -r CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/.* . This was running for a while and then i lost my connection and cant reconnect. I won't have console access till the morning but any advice would be greatly appreciated. Don't you mean: scp -rp CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/. . ? The command you list above won't copy anything, since there are no dotfiles in the root directory. Also, you have backup2 in the rsync command and backup1 in the scp command. Maybe that was just a typo though... As never having restored anything more that a few files at a time as the Linux newbie that I am, I'm sure i was off. Thanks for the tip again :) Typo it was. Should have been backup2 in the scp command. One final thought. Sometimes scp has issues with symlinks (as in, copying the target instead of the link). Might want to use: cd / rsync -av CENTRAL_SERVER_IP:/backup1/BACKED_UP_SERVER_FQDN/current/ . I will try this first thing in the morning when I have console access. Just one more thing; Based on the script I use, am I SOL or with a little elbow greese in the morning get my server back? Thank you for your time and advice. I really appreciate it! Mark Mike -- To unsubscribe or change options: http://lists.samba. org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: --exclude and --delete-exclude problem
On Thu, Jan 09, 2003 at 01:20:08AM -0400, Carlos Molina wrote: Hi. I'm trying to accomplish the following ; 1) First, I did a rsync for a file, like this /usr/bin/rsync -lptgoD --delete --rsh=/usr/bin/ssh -R --delete-excluded -vv [EMAIL PROTECTED]:/usr/local/src/* /tmp/localhost/daily.0 Remove the '*'. In order for rsync to delete a file, it needs to deal with the directory that the files are in and the '*' tells it to only deal with the files in the directory. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: IPv6 hosts allow|deny
I went ahead and submitted Hideaki's patch pretty much as is. I took off the ifdef around the memset at the beginning of client_sockaddr() because I figured it wouldn't hurt to do anywhere. Besides, it was checking for a specific operating system (__linux__) which we like to avoid and because there was a typo in the check for HAVE_SOCKADDR_IN6_SCOPE_ID (it was HAVE_SOCKADDR_IN6_SOCPE_ID). I noticed that there was code in access.c that was accessing the same sockaddr_in6 sin6_scope_id field that was protected by ifdef in clientname.c so I put the same ifdef around the code in access.c. I also updated the rsyncd.conf.yo documentation to allow for IP address of the IPv6 form. I have not tested this, I hope it works. - Dave On Wed, Jan 08, 2003 at 08:24:13AM -0600, Dave Dykstra wrote: On Wed, Jan 08, 2003 at 12:25:15AM +0100, Bert Vermeulen wrote: On Tue, 7 Jan 2003, Dave Dykstra wrote: Even though rsync maintenance isn't as bad as wget's, the maintainers are all VERY part time so that is a big part of the problem. Most of us don't have ipv6 systems to test things on. Can you vouch for the quality of the patch? I was able to get it with wget --passive ftp://ftp.linux-ipv6.org/pub/usagi/misc/rsync-2_5_5-v6auth-20021016.patch.gz and it looks quite extensive. Yes, it's very extensive, and there's some code in there that's pretty advanced. The fact of the matter is, I made my own patch for this functionality first, and only then noticed Hideaki's patch -- and his, while not as readable to the casual observer, seems like better code. He is rewriting the linux kernel IPv6 stack, so I'd expect his rsync patch to be decent :-) Nevertheless, feel free to take a look at my patch: http://biot.com/patches/rsync-ipv6-acl.patch So I haven't used Hideaki's patch, but I use mine, and it's good. Please do apply one of them however. Since you're more familiar with that area of the code than any of the rsync maintainers and you think his patch is better, please test out his patch and look it over to see if you think there should be any changes. In particular, I see that yours includes documentation changes and his doesn't. - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 11:21:36PM +0100, Lapo Luchini wrote: jw schultz wrote: The 2 second timestamp resolution only applies to some windows filesystems. I think NTFS has timestamp resolution in the milliseconds (unlrelated to precision). It should only become an issue when the windows filesystem is the destination. This message says it is 2 seconds aso on NTFSD actually: http://lists.samba.org/pipermail/rsync/2000-July/002491.html I don't use windows myself. I just recall that one of the windows filesystem has timestamps in the milliseconds. Further examination shows that it is already hacked in options.c for win32: | #ifdef _WIN32 | int modify_window=2; | #else | int modify_window=0; | #endif perhaps something just needs to be added to the #ifdef. Ohhh... I'd add CygWin to the #ifdef too, then. Grr, I *never* remember what does cygwin define and what not ^_^ Let me check... this message http://sources.redhat.com/ml/gdb-patches/2001-04/msg00039.html suggests that to include djgpp, mingw and cygwin the full ifdef should be: #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__) Should I add that to the current 2.5.5 cygwin port (creating a -3 release) or 2.5.6 will be short in time? Depends on how urgent this is. Given you have a workaround i'd get it in cvs and wait. Assuming the 2.5.6 really does happen soon. Please try a modify-window of 1. Maybe my math is off somehow but i don't think it needs to be greater than 1. Take a look at the code in util.c. If you truncate to 2 second resolution and compare against 1 second resolution the difference should never be greater than 1 second. It won't make a difference very often but i'd still feel better making the window as small as possible. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
jw schultz wrote: This message says it is 2 seconds aso on NTFSD actually: http://lists.samba.org/pipermail/rsync/2000-July/002491.html I don't use windows myself. I just recall that one of the windows filesystem has timestamps in the milliseconds. I also thought that, but that mesage says that the various times (creation/modification/access) have *different* resolution 0_o (it seems crazy to me, but 'realistic' in a strangely Microsoft way ^_^) Depends on how urgent this is. Given you have a workaround i'd get it in cvs and wait. Assuming the 2.5.6 really does happen soon. I was just aksing about that.. I usually do packages once or twice a month, if 2.5.6 is not that far I'd way it ^_^ Please try a modify-window of 1. Maybe my math is off somehow but i don't think it needs to be greater than 1. Take a look at the code in util.c. If you truncate to 2 second resolution and compare against 1 second resolution the difference should never be greater than 1 second. It won't make a difference very often but i'd still feel better making the window as small as possible. If it is done with a granularity equal to the modification-time I'd agree, but if granularity is greater you could as well have 2-epsilon time difference (epsilon being the granularity).. isn't it? I've not yet seen the code anyway, so I should shut up =) -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
working on a 2.5.6pre1 release
I'm working on trying to get rsync 2.5.6pre1 available for people to test more widely. I'm out of time for today, and I'm stuck on a problem that some machines on build.samba.org are showing on the 'chgrp' test. I can reproduce this on my home redhat 7.3 system too. It appears to be a timing problem because when I do strace -F -f on it the problem goes away. Everything seems to go through normally but then it exits with an exit code of 12, I think because the child receiver process is terminated with a SIGUSR2 which is signal 12 and because the bug that was preventing exit codes from being properly reported from children has now been fixed. It's very hard to debug because it is a timing problem and because it happens after rprintf handling is already shut down in the child process. I suspected that maybe the catching of the SIGUSR2 signal was not getting inherited from its parent, but it doesn't help to re-set it in the child. Nevertheless, I'm not sure whether or not the sigusr2_handler function is getting called in the child. I'd appreciate some help with this if anybody else thinks they can figure it out. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: working on a 2.5.6pre1 release
On Thu, Jan 09, 2003 at 05:09:07PM -0600, Dave Dykstra wrote: I'm working on trying to get rsync 2.5.6pre1 available for people to test more widely. I'm out of time for today, and I'm stuck on a problem that some machines on build.samba.org are showing on the 'chgrp' test. I can reproduce this on my home redhat 7.3 system too. It appears to be a timing problem because when I do strace -F -f on it the problem goes away. Everything seems to go through normally but then it exits with an exit code of 12, I think because the child receiver process is terminated with a SIGUSR2 which is signal 12 and because the bug that was preventing exit codes from being properly reported from children has now been fixed. It's very hard to debug because it is a timing problem and because it happens after rprintf handling is already shut down in the child process. I suspected that maybe the catching of the SIGUSR2 signal was not getting inherited from its parent, but it doesn't help to re-set it in the child. Nevertheless, I'm not sure whether or not the sigusr2_handler function is getting called in the child. I'd appreciate some help with this if anybody else thinks they can figure it out. I haven't pinned it down but the problem appears to have been introduced in 1.157 of main.c with the lost exist status patch. I was able to reproduce your error on the chgrp test and backing out to 1.156 fixed it. That at least narrows it down. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
make clean
I just did a make clean to tidy up a bit and found four objects were missed. The seem to belong to the CHECK_PROGS set. Not sure where best to put them so created a CHECK_OBJS variable and added it to the clean rule. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt Index: Makefile.in === RCS file: /cvsroot/rsync/Makefile.in,v retrieving revision 1.84 diff -u -r1.84 Makefile.in --- Makefile.in 8 Apr 2002 06:23:34 - 1.84 +++ Makefile.in 10 Jan 2003 02:40:34 - @@ -43,6 +43,9 @@ # Programs we must have to run the test cases CHECK_PROGS = rsync tls getgroups trimslash t_unsafe +# Objects for CHECK_PROGS to clean +CHECK_OBJS=getgroups.o t_stub.o t_unsafe.o trimslash.o + # note that the -I. is needed to handle config.h when using VPATH .c.o: @OBJ_SAVE@ @@ -106,7 +109,7 @@ cat $(srcdir)/*.c $(srcdir)/lib/compat.c | awk -f $(srcdir)/mkproto.awk $(srcdir)/proto.h clean: cleantests - rm -f *~ $(OBJS) rsync $(TLS_OBJ) $(CHECK_PROGS) + rm -f *~ $(OBJS) rsync $(TLS_OBJ) $(CHECK_PROGS) $(CHECK_OBJS) cleantests: rm -rf ./testtmp*
Re: working on a 2.5.6pre1 release
On Thu, Jan 09, 2003 at 05:09:07PM -0600, Dave Dykstra wrote: It's very hard to debug because it is a timing problem and because it happens after rprintf handling is already shut down in the child process. Fortunately fprintf(stderr, ...) always works, even in the child process. This is what I've been using to get some status on the problem. Everything seems to go through normally but then it exits with an exit code of 12, I think because the child receiver process is terminated with a SIGUSR2 which is signal 12 and because the bug that was preventing exit codes from being properly reported from children has now been fixed. The value of SIGUSR2 is a red herring. The error is really RERR_STREAMIO, which is being returned by the whine_about_eof() routine. I haven't had time to figure out why this code is getting sent during the final phase of the life of the receiver yet, though. The receiver successfully kills the generator, gets its 0 status code, begins to return a 0 status code, and then it suddenly starts exit_cleanup() over again with the error 12 from the io.c code. One thing I have discovered is that if I remove the two rprintf() calls from exit_cleanup() (changing them into fprintf(stderr) calls), I can't get the test to fail. My current theory is that the sender is closing down the socket, and if the receiver just happens to get past the two rprintf()s before this happens, then all is well. If not, it gets an error (since something must be trying to flush during the exit_cleanup(0) processing) and switches to an exit of 12 (RERR_STREAMIO). I'll finish debugging this later if no one else gets to it first. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
jw schultz wrote: The 2 second timestamp resolution only applies to some windows filesystems. I think NTFS has timestamp resolution in the milliseconds (unlrelated to precision). It should only become an issue when the windows filesystem is the destination. This message says it is 2 seconds aso on NTFSD actually: http://lists.samba.org/pipermail/rsync/2000-July/002491.html Further examination shows that it is already hacked in options.c for win32: | #ifdef _WIN32 | int modify_window=2; | #else | int modify_window=0; | #endif perhaps something just needs to be added to the #ifdef. Ohhh... I'd add CygWin to the #ifdef too, then. Grr, I *never* remember what does cygwin define and what not ^_^ Let me check... this message http://sources.redhat.com/ml/gdb-patches/2001-04/msg00039.html suggests that to include djgpp, mingw and cygwin the full ifdef should be: #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__) Should I add that to the current 2.5.5 cygwin port (creating a -3 release) or 2.5.6 will be short in time? -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
CVS update: rsync
Date: Thu Jan 9 21:14:10 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv5654 Modified Files: NEWS access.c acconfig.h clientname.c config.h.in configure configure.in rsyncd.conf.5 rsyncd.conf.yo Log Message: Support IPv6 addresses with hosts allow and hosts deny. Patch from Hideaki Yoshifuji. Revisions: NEWS1.80 = 1.81 http://www.samba.org/cgi-bin/cvsweb/rsync/NEWS?r1=1.80r2=1.81 access.c1.5 = 1.6 http://www.samba.org/cgi-bin/cvsweb/rsync/access.c?r1=1.5r2=1.6 acconfig.h 1.13 = 1.14 http://www.samba.org/cgi-bin/cvsweb/rsync/acconfig.h?r1=1.13r2=1.14 clientname.c1.13 = 1.14 http://www.samba.org/cgi-bin/cvsweb/rsync/clientname.c?r1=1.13r2=1.14 config.h.in 1.73 = 1.74 http://www.samba.org/cgi-bin/cvsweb/rsync/config.h.in?r1=1.73r2=1.74 configure 1.142 = 1.143 http://www.samba.org/cgi-bin/cvsweb/rsync/configure?r1=1.142r2=1.143 configure.in1.149 = 1.150 http://www.samba.org/cgi-bin/cvsweb/rsync/configure.in?r1=1.149r2=1.150 rsyncd.conf.5 1.45 = 1.46 http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.5?r1=1.45r2=1.46 rsyncd.conf.yo 1.50 = 1.51 http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.yo?r1=1.50r2=1.51 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
