feedback on rsync-HEAD-20050125-1221GMT
Alberto Accomazzi
aaccomazzi at cfa.harvard.edu
Fri Jan 28 16:25:06 GMT 2005
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
********************************************************************
More information about the rsync
mailing list