feedback on rsync-HEAD-20050125-1221GMT

[Alberto Accomazzi]

Wayne Davison wrote:

>>I'm also looking forward to hearing news about the --filter option.  I'm 
>>thinking it is going to be very useful for backup purposes.  What I 
>>would want to be able to do is, on a per-directory basis and with 
>>recursion as an option, enable or disabled backing up of files based on 
>>their file name, size, and timestamp (maybe mtime only would suffice). 
>>Is this where you're going?
> 
> 
> It already supports per-directory name rules, both inherited and not.
> The idea of having per-directory size and time limits would not be hard
> to add, and may be quite worthwhile.  For instance, assume 's' is for
> size and 't' is for the modified time:
> 
>     # Don't transfer files 1 GB or larger
>     s< 1g
>     # Don't transfer files 100 KB or smaller
>     s> 100k
>     # Only transfer new files (modified in the last day)
>     t> yesterday
> 
> Something like that, perhaps.

Oooh, I see we are getting a little ambitious, aren't we? ;-)
I like the idea, I'm just worried about coming up with yet a new syntax 
for these types of operations.  I think we should stick with something 
"standard" or at least close to what people are used to already.  So 
what comes to mind is the syntax used by find(1) for its tests:

tests (N can be +N or -N or N): -amin N -anewer FILE -atime N -cmin N
    -cnewer FILE -ctime N -empty -false -fstype TYPE -gid N -group NAME
    -ilname PATTERN -iname PATTERN -inum N -ipath PATTERN -iregex PATTERN
    -links N -lname PATTERN -mmin N -mtime N -name PATTERN -newer FILE
    -nouser -nogroup -path PATTERN -perm [+-]MODE -regex PATTERN
    -size N[bckw] -true -type [bcdpfls] -uid N -used N -user NAME
    -xtype [bcdpfls]

Now, this is way beyond what any of us is likely to need, but if we can 
reuse find's code to do everything we need to do, why not?

The only other thing that comes to mind would be to have, as an option, 
a filter program that acts as a bidirectional pipe: it's given as input 
the filename under consideration and it returns a 1 or a 0 depending on 
whether the file needs to be processed or not.  This sounds like the 
most flexible approach, but in my experience dealing with bidirectional 
pipes is asking for trouble, because it's so easy to screw things up 
with buffering, so this is probably not a good general solution.

>>- when running in daemon mode on fedora core 2, the daemon does not 
>>start up properly unless you use the option --ipv4.
> 
> 
> The code tries to deal with this case by forcing the IPv6 version of the
> bind() to only bind the IPv6 port, not both IPv4 and IPv6:
> 
> #ifdef IPV6_V6ONLY
> 	if (resp->ai_family == AF_INET6) {
> 		if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
> 			       (char *)&one, sizeof one) < 0
> 		    && default_af_hint != AF_INET6) {
> 			close(s);
> 			continue;
> 		}
> 	}
> #endif
> 
> Do you know if FC2 has IPV6_V6ONLY defined?

It appears that it doesn't.

> The code does output the warning you mentioned when it thinks that this
> bug is in effect.  I could have the code ignore the failure of the
> second listen() call when this happens, but that would make rsync only
> listen on the IPv4 address, and I think that it is better to ask the
> user to specifically ask us to do that (via -4) rather than to output a
> warning and assume that is OK to start up with reduced binding.

Actually I think the reason for this is that I was running on a FC2 box 
an executable built under RH 7.3.  The versions of libc are enough far 
apart to expect some trouble of this kind.  When I compile and run rsync 
under FC2 the error is gone.

One more thing to point out: I got a core dump when starting a daemon 
which tried to write to a log file that it had no permission to write 
to.  The problem seems to be that the function log_open in log.c does 
not check the return value of fopen.  I don't know whether the right 
thing to do would be to exit with an error or continue but without 
logging, but something ought to be changed.


-- Alberto



********************************************************************
Alberto Accomazzi                      aaccomazzi(at)cfa harvard edu
NASA Astrophysics Data System                        ads.harvard.edu
Harvard-Smithsonian Center for Astrophysics      www.cfa.harvard.edu
60 Garden St, MS 31, Cambridge, MA 02138, USA
********************************************************************