rsync - Nov 2002 - "Doh!", or: The Sync'ing Feeling I Get With Recursion

This message describes (imho) a behaviour bug in rsync.  I'm going
to submit a patch, but before I dive into the code I want to know what the
actual desired behaviour should be.  In other words, please comment.

	I have some directories I want to keep synchronised between two
machines (call them "master" and "backup").

	Every now and then someone deletes a file on "master".  When that
happens I want to sync the containing directory (in order to have that
doomed file deleted on "backup").  But here's the catch; I do NOT
want to
recurse into all subdirectories.  I ONLY want that one file to be deleted,
by rsync'ing the containing dir with the --delete option.  This is in a
big dir tree with many subdirs, and it's too expensive for me to sync up
all subdirs when a single file near the top has been deleted.

	How to make this happen?

	I tried doing an rsync of just the deleted filename.  But no,
rsync says "That source file does not exist", which makes sense.

	I tried doing an rsync of the containing directory.  But no,
unless -r or -a is specified (for recursion) directories are ignored
ALTOGETHER, even if you put a trailing '/' on the dirname.  According to
the documentation, a trailing '/' should cause a sync of that dir's
contents.  But that will only happen when you're in recursive mode (-r).
If you're not in recursive mode, it says "Skipping directory ...",
even
though it has a trailing '/'.

	Am I missing something?  Any other ideas on things to try?


	So here are the two possible fixes I would like to implement:

1. Add a --max-recursion-depth option

	I could then set this to "1" and have my problem solved.  Setting
--max-recursion-depth to "0" would be the same as not specifying -r.
That is, setting it to zero would disable sync'ing of directories
altogether (which is the default behaviour now without the -r).

Pros: Might be generally useful to other individuals, does not change
current behaviour
Cons: Yet another special-interest-group option for the docs


2. Change the current behaviour for sources that end in '/'

	I could make is so that dirs are ignored when there is no -r,
UNLESS the source name has a trailing '/'.  In that case, the contents
of
that dir will by sync'd (with or without recursion, depending on if -r is
given).

Pros: Just a simple bugfix, no doc updates necessary, and seems most
logical to me
Cons: Probably tougher to implement (?), changes pre-existing behaviour


	Which do people prefer?  I'm looking for the change most likely to
make it into the main distribution.


Thanks,
Derek

On Tue, Nov 05, 2002 at 12:46:35PM -0500, Derek Simkowiak
wrote:
> 
> 	This message describes (imho) a behaviour bug in rsync.  I'm going
> to submit a patch, but before I dive into the code I want to know what the
> actual desired behaviour should be.  In other words, please comment.
> 
> 	I have some directories I want to keep synchronised between two
> machines (call them "master" and "backup").
> 
> 	Every now and then someone deletes a file on "master".  When
that
> happens I want to sync the containing directory (in order to have that
> doomed file deleted on "backup").  But here's the catch; I do
NOT want to
> recurse into all subdirectories.  I ONLY want that one file to be deleted,
> by rsync'ing the containing dir with the --delete option.  This is in a
> big dir tree with many subdirs, and it's too expensive for me to sync
up
> all subdirs when a single file near the top has been deleted.
Yours is a very unusual request.  A directory isn't in sync
unless all its subdirs are.
> 1. Add a --max-recursion-depth option
> 
> 	I could then set this to "1" and have my problem solved. 
Setting
> --max-recursion-depth to "0" would be the same as not specifying
-r.
> That is, setting it to zero would disable sync'ing of directories
> altogether (which is the default behaviour now without the -r).
> 
> Pros: Might be generally useful to other individuals, does not change
> current behaviour
> Cons: Yet another special-interest-group option for the docs
This can be accomplihed with --exclude
	/*/	== no recursion
	/*/*/	== only top level subdirs
	/*/*/*/	== only top two levels

It doesn't need another option.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt