specifying a list of files to transfer

Dave Dykstra dwd at drdykstra.us
Fri Jan 17 22:44:00 EST 2003

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

> 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.

- Dave

More information about the rsync mailing list