Hi, We've found a need to list the files to transfer in a files since our command lines got too long. Anyway, the attached patch implements reading from a file with two command line options. The first is from-file, this file contains a list of files to get from src. The second is subst-file which contains a list of files to send to dst. e.g. rsync -f rsync.files jim@server::jim/ . and rsync -s rsync.files jim@server::jim The first will grab the files listed in rsync.files from server::jim and put them in '.' . The second will send the files listed in rsync.files to server::jim . Other than adding those options this patch also creates a new function send_a_file() which makes send_file_list() a bit shorter and easier to read. Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_subst_from_file_rsync.diff Type: text/x-patch Size: 25301 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20031210/fe71d2db/01_subst_from_file_rsync.bin
On Wed, Dec 10, 2003 at 07:49:51PM -0500, James A. Morrison wrote:> Hi, > > We've found a need to list the files to transfer in a files since > our command lines got too long. Anyway, the attached patch > implements reading from a file with two command line options. > > The first is from-file, this file contains a list of files to get > from src. The second is subst-file which contains a list of files > to send to dst. > > e.g. > rsync -f rsync.files jim@server::jim/ . > > and > > rsync -s rsync.files jim@server::jim > > The first will grab the files listed in rsync.files from > server::jim and put them in '.' . The second will send the > files listed in rsync.files to server::jim .see the --files-from option in CVS -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
> On Wed, Dec 10, 2003 at 07:49:51PM -0500, James A. Morrison wrote: > > Hi, > > > > We've found a need to list the files to transfer in a > files since our > > command lines got too long. Anyway, the attached patch implements > > reading from a file with two command line options. > > > > The first is from-file, this file contains a list of files to get > > from src. The second is subst-file which contains a list > of files to > > send to dst. > > > > e.g. > > rsync -f rsync.files jim@server::jim/ . > > > > and > > > > rsync -s rsync.files jim@server::jim > > > > The first will grab the files listed in rsync.files from > server::jim > > and put them in '.' . The second will send the files listed in > > rsync.files to server::jim . > > see the --files-from option in CVSWhat is the proper way to patch rsync? I don't seem to be having any luck with: patch [options] [originalfile [patchfile] I need something like this and would like to play around with it on a dev box. Or is this identical to --files-from option? I'd like to be able to just list the files to be rsynced with the full path in a file. I currently use the --include-from option and understand it pretty well now, but I'm working on an automated process for selecting files and this type of option would make the script logic much easier. Thanks, Max
On Wed, Dec 10, 2003 at 07:49:51PM -0500, James A. Morrison wrote:> e.g. > rsync -f rsync.files jim@server::jim/ . > and > rsync -s rsync.files jim@server::jimIn CVS, both directions use the same --files-from option, and this file can be read from either side of the connection. e.g., these are all equivalent, with just the difference in transport (daemon vs ssh) and the difference of which side the rsync.files file is read: rsync --files-from=rsync.files jim@server::jim/ . rsync --files-from=rsync.files server:/path/jim/ . rsync --files-from=server:/path/jim/rsync.files server:/path/jim/ . rsync --files-from=:rsync.files jim@server::jim/ . and rsync --files-from=rsync.files . jim@server::jim rsync --files-from=rsync.files . server:/path/jim rsync --files-from=:/path/jim/rsync.files . server:/path/jim rsync --files-from=server:rsync.files . jim@server::jim The leading ':' is a short-hand for referring to the same server-name as the server in the transfer (since it has to be the same name, I recommend just prefixing the name with a colon to indicate that it is remote). Some differences in our implementations: The CVS version assumes the --relative option with --files-from so that the paths are preserved. The --no-relative option was added to allow you to turn this off. The CVS version tweaks -a (--archive) to not imply -r (--recursive) when used with --files-from. Combined with the feature that any named directories are created on the destination, this allows the user to use the traditional "-av" options and get only the files and directories specified sent to the destination system and no others (specify -ar if you want to send named directories with recursion). BUG: It looks like combining --files-from with a daemon pull and a local file-list currently hangs during the transfer of file names (it succeeds in the other 3 modes of daemon transfer, and in all 4 modes of remote-shell transfer). I'll fix this.> Other than adding those options this patch also creates a new function > send_a_file() which makes send_file_list() a bit shorter and easier to > read.I'll take a look at that. Your patch also added an "(x of y)" display during the transfer which I will also consider (though I'd only want such extra output in the --progress mode). ..wayne..