specifying a list of files to transfer

[jw schultz]

On Fri, Jan 17, 2003 at 04:42:51PM -0600, Dave Dykstra wrote:
> On Thu, Jan 16, 2003 at 11:14:50PM -0800, Wayne Davison wrote:
> > On Thu, Jan 16, 2003 at 07:06:05PM -0800, jw schultz wrote:
> > > [...] and that entries therein are not flattened like they would be on
> > > the command-line (sans -R).
> > 
> > But they *are* flattened exactly like on the command-line, at least in
> > my current patch they are.  That's what -R is for -- telling rsync not
> > to do that.  So, without -R there are no implied directories to create
> > except for the destination dir (which is created if it doesn't exist).
> 
> Oh, right, I hadn't thought of that implication of the way this is
> implemented.  Definitely we want the -R functionality implied.  That's
> the only way I can imagine people wanting to use this.
> 
> 
> 
> > > The permissions and ownership should be derived from the source.
> > > so effectively it should be as though
> > > 	./deltapics
> > > where in the file list.
> > 
> > Right.  In fact, that's exactly what happens with -R -- all intermediate
> > directories get added to the file list (if they aren't already in it)
> > without causing any extra recursion (even if -r was specified/implied).
> 
> 
> In my former hack implementation of the "exclude optimization" (when 
> there were only includes with no wildcards and a final exclude '*') it
> was able to skip sending the parent directories completely.  Come to
> think of it, I'm not sure what kind of permissions were used for the
> directories that were not explicitly included, maybe it just use the
> default.
> 
> 
> > If people want the "--files-from" to imply "-R" then I'd want to see a
> > "--no-relative" option to let people turn it off.
> 
> That would be easy to implement so I guess it wouldn't hurt but I really
> can't see people wanting to do that.

	rsync -lptgoDu --delete --files-from=distlist distserver::8.0/i386 /root2
where distlist is
	etc/init.d/rsyncd
	etc/rsyncd.conf
	usr/bin/rsync
	usr/bin/rsyncstats
	usr/sbin/rcrsyncd
	usr/sbin/rsyncd
	usr/share/doc/packages/rsync
	usr/share/doc/packages/rsync/COPYING
	usr/share/doc/packages/rsync/README
	usr/share/doc/packages/rsync/tech_report.ps
	usr/share/doc/packages/rsync/tech_report.tex
	usr/share/man/man1/rsync.1.gz
	usr/share/man/man5/rsyncd.conf.5.gz

It should not do /root2/i386/etc/init.d/rsyncd and so on as
-R would have it.

It should not create (flattened)
	/root2/rsyncd		# from /etc/init.d
	/root2/rsyncd.conf
	/root2/rsync
	/root2/rsyncstats
	/root2/rcrsyncd
	/root2/rsyncd		# from usr/sbin?
	/root2/COPYING
	/root2/README
	/root2/tech_report.ps
	/root2/tech_report.tex
	/root2/rsync.1.gz
	/root2/rsyncd.conf.5.gz

What it should create or update is /root2/etc/init.d/rsyncd and so on.
and it should be equivalent to
	rsync -lptgoDu --delete --files-from=distlist \
		distserver:/data/distribution/8.0/i386 /root2
or
	rsync -lptgoDu --delete --files-from=distlist \
		/data/distribution/8.0/i386 client:/root2


If /root2/usr/share/doc/packages doesn't exist it should be
created with perms from source but it should not be recoursed.

This example is drawn from one of the most recent emails
requesting this feature.

I want to thank Wayne for his work on this and his patience
with me.  I seem to be butting heads with him while he has
been good enough to actually write code.  I hope this points
out clearly the difference in our perspectives on this.  I
am not talking about a way to extend the command line.  I am
talking about an explicit list that eliminates the tree walk
and awkwardness of artificial include/exclude lists and has
a similar effect to

	while read subpath
	do
		rsync -lptgoD distserver::8.0/i386/$subpath /root2/$subpath
	done <distlist

which is what people are actually doing now.

There is i'm sure value in being able to pass a list that
simply won't fit on the command line.

There is however immediate value in being able to request
a sparse list of paths to be synced from one tree to another
without looping or changing CWD (especially on the remote
end).

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

		Remember Cernan and Schmitt