On Fri, Jan 17, 2003 at 05:42:41PM -0800, Wayne Davison wrote:
> On Fri, Jan 17, 2003 at 04:21:59PM -0800, jw schultz wrote:
> > It should not do /root2/i386/etc/init.d/rsyncd and so on as
> > -R would have it.
>
> -R would only do that if you actually prefixed the paths with the source
> dir, wh
On Fri, Jan 17, 2003 at 04:21:59PM -0800, jw schultz wrote:
> It should not do /root2/i386/etc/init.d/rsyncd and so on as
> -R would have it.
-R would only do that if you actually prefixed the paths with the source
dir, which is not what happens with --files-from. The source dir is
just used as t
---begin quoted text---
> From: jw schultz <[EMAIL PROTECTED]>
> Date: Fri, 17 Jan 2003 16:21:59 -0800
>
> 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:
> >
> > Oh, right, I hadn't thought of that implication of th
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
On Fri, Jan 17, 2003 at 11:46:33AM -0500, Andrew J. Schorr wrote:
> Is there a possible case where
> the --files-from file list lives on the remote (sender) side?
Yes, I could see that being possible -- your update scenario is even an
interesting example.
It's actually easy to have the remote sen
On Fri, Jan 17, 2003 at 12:14:13PM -0500, Andrew J. Schorr wrote:
> If I run rsync in such a way that parent directories are sent automatically,
> it will send the following files (based on -vvv output):
>
>make_file(4,test)
>make_file(4,test/foo.jpg)
>make_file(4,test/bar.jpg)
>ma
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
On Thu, Jan 16, 2003 at 07:06:05PM -0800, jw schultz wrote:
> I know i'm not talking about when -R is used. I am talking
> about creating implied intermediate directories without -R.
> I'm talking about being able to take the output of
> find -name '*.jpg' and have it create (if necessary) any
> i
On Thu, Jan 16, 2003 at 05:07:13PM -0800, Wayne Davison wrote:
> (I assume you're talking about when using -R, which is not currently on
> by default.) I believe that we do need an auto-creation mode and also a
> way to optimize the transfer to avoid this (since it results in a lot of
> extra dire
On Thu, Jan 16, 2003 at 01:58:49PM -0800, jw schultz wrote:
> On Thu, Jan 16, 2003 at 02:52:38PM -0600, Dave Dykstra wrote:
> > Also, if the transfer is being sent from the remote side, the file names
> > are all getting sent over to the remote side first for --files-from and
> > then sent back as
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 rsy
On Thu, Jan 16, 2003 at 05:07:13PM -0800, Wayne Davison wrote:
> > On Wed, Jan 15, 2003 at 02:49:08PM -0800, jw schultz wrote:
> > > You seem to see the files-from as a way of replacing command-line
> > > args where i see it as a way of replacing the tree scan.
>
> I actually think of it as both,
> On Wed, Jan 15, 2003 at 02:49:08PM -0800, jw schultz wrote:
> > You seem to see the files-from as a way of replacing command-line
> > args where i see it as a way of replacing the tree scan.
I actually think of it as both, since I also consider the command-line
as a way of replacing the tree sca
On Thu, Jan 16, 2003 at 02:52:38PM -0600, Dave Dykstra wrote:
> Also, if the transfer is being sent from the remote side, the file names
> are all getting sent over to the remote side first for --files-from and
> then sent back as part of the normal protocol, right? I had hoped we'd
> be able to a
On Wed, Jan 15, 2003 at 02:49:08PM -0800, jw schultz wrote:
> On Wed, Jan 15, 2003 at 10:03:33AM -0800, Wayne Davison wrote:
> > On Tue, Jan 14, 2003 at 07:57:48PM -0800, jw schultz wrote:
> > > with the -r or -a options does this [recurse] on
> > > directories in the --files-from list?
> >
> > Ye
I like it (except for the work). I don't think I'm ready to code up a
filter yet, but it is good to know the general theory in case I need to use
it. Of course, if I keep thinking about it I'll probably run across a
situation where it's use would greatly speed/simplify my life, so maybe I
should
On Wed, Jan 15, 2003 at 10:03:33AM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 07:57:48PM -0800, jw schultz wrote:
> > with the -r or -a options does this [recurse] on
> > directories in the --files-from list?
>
> Yes, it treats them like command-line args with the following two
> except
On Wed, Jan 15, 2003 at 02:48:05PM -0600, Lee Eakin wrote:
> Now if I can only figure out a way to intercept the list when I need to
> be real picky about which individual files are accessed ...
This should be possible with a filter process. Here's how the new,
slightly tweaked protocol works:
1
---begin quoted text---
> From: Wayne Davison <[EMAIL PROTECTED]>
> Subject: Re: specifying a list of files to transfer
> Date: Wed, 15 Jan 2003 10:10:29 -0800
>
> On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote:
> > Yes, people do restrict args via ssh k
On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote:
> Yes, people do restrict args via ssh key restrictions.
OK, I thank you both for enlightening me on the subject. My current
patch applies the sanitize_path() function to all names read via the
--files-from option, regardless of whether w
On Tue, Jan 14, 2003 at 07:57:48PM -0800, jw schultz wrote:
> with the -r or -a options does this [recurse] on
> directories in the --files-from list?
Yes, it treats them like command-line args with the following two
exceptions: if -r is not specified, we WILL create an explicitly named
directory
> From: jw schultz <[EMAIL PROTECTED]>
> Date: Tue, 14 Jan 2003 20:33:46 -0800
>
> On Tue, Jan 14, 2003 at 10:15:42PM -0600, Lee Eakin wrote:
> > ---begin quoted text---
> > > From: jw schultz <[EMAIL PROTECTED]>
> > > Date: Tue, 14 Jan 2003 20:07:58 -0800
> > >
> > > Nope. The files-from conten
On Tue, Jan 14, 2003 at 10:15:42PM -0600, Lee Eakin wrote:
> ---begin quoted text---
> > From: jw schultz <[EMAIL PROTECTED]>
> > Date: Tue, 14 Jan 2003 20:07:58 -0800
> >
> > Nope. The files-from contents needs to passed on stdin otherwise
> > we would hit command-line length limits. That is wh
---begin quoted text---
> From: jw schultz <[EMAIL PROTECTED]>
> Date: Tue, 14 Jan 2003 20:07:58 -0800
>
> Nope. The files-from contents needs to passed on stdin otherwise
> we would hit command-line length limits. That is why i'm
> stressing the fact that allowing paths not within the source
>
On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote:
> Please pardon my butting in again. I am not a developer, but I am very
> interested in this option because I've need it in the past and had to work
> around the lack of it with include/exclude options (I wanted to sync only
> a few files
Please pardon my butting in again. I am not a developer, but I am very
interested in this option because I've need it in the past and had to work
around the lack of it with include/exclude options (I wanted to sync only
a few files from a large directory, and needed it to work via the daemon
for a
On Tue, Jan 14, 2003 at 07:39:49PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 07:02:58PM -0800, jw schultz wrote:
> > Up till now rsync hasn't touched anything outside of the paths
> > specified on the command-line. Changing that would mean access to
> > rsync via ssh would no longer be
On Tue, Jan 14, 2003 at 09:15:02PM -0600, Lee Eakin wrote:
> FYI, pulling multiple files from a daemon currently supported (well, it
> works). Given a package of foo you can specify:
>
> rsync -av 'remote::foo/file1 foo/file5' /tmp
Oh! I had left off the repeat of the module name when I tried
On Tue, Jan 14, 2003 at 07:02:58PM -0800, jw schultz wrote:
> Up till now rsync hasn't touched anything outside of the paths
> specified on the command-line. Changing that would mean access to
> rsync via ssh would no longer be restricted, just disabled.
Are you saying that some people have speci
o the remote end (of course there
may be limits depending on what login shell is used on the remote server).
-Lee
---begin quoted text---
> From: Wayne Davison <[EMAIL PROTECTED]>
> To: jw schultz <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: specifying a list of
On Tue, Jan 14, 2003 at 06:41:22PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 04:35:40PM -0800, jw schultz wrote:
> > Absolute paths are bad news here. Especially when dealing with an
> > rsync daemon.
>
> Yes, this is something that needs to be dealt with for daemon mode since
> it do
On Tue, Jan 14, 2003 at 04:35:40PM -0800, jw schultz wrote:
> Absolute paths are bad news here. Especially when dealing with an
> rsync daemon.
Yes, this is something that needs to be dealt with for daemon mode since
it does not appear to have been possible to specify multiple filenames
to pull b
On Tue, Jan 14, 2003 at 03:57:51PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 03:32:41PM -0600, Dave Dykstra wrote:
> > 1. Yes it should take a filename or - as a parameter.
> > 2. I don't like the idea of skipping the SRC spec. Paths should be
> > relative to the SRC. If s
On Tue, Jan 14, 2003 at 03:32:41PM -0600, Dave Dykstra wrote:
> 1. Yes it should take a filename or - as a parameter.
> 2. I don't like the idea of skipping the SRC spec. Paths should be
> relative to the SRC. If somebody wants to use full paths they
> can always have a SRC of
On Tue, Jan 14, 2003 at 03:32:41PM -0600, Dave Dykstra wrote:
> I haven't looked at the implementation, but comments on the user
> interface:
> 1. Yes it should take a filename or - as a parameter.
> 2. I don't like the idea of skipping the SRC spec. Paths should be
> relative to the
On Tue, Jan 14, 2003 at 01:21:29PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 11:02:44AM -0500, Andrew J. Schorr wrote:
> > I am attaching an updated version of my patch to allow you to specify
> > a list of files to transfer.
>
> Cool. I'm looking into making this work when fetching f
On Tue, Jan 14, 2003 at 11:02:44AM -0500, Andrew J. Schorr wrote:
> I am attaching an updated version of my patch to allow you to specify
> a list of files to transfer.
Cool. I'm looking into making this work when fetching files. Towards
that end, I'd like to suggest an alternate command-line sy
Hi,
I don't want to start another --files-from war, but I am attaching
an updated version of my patch to allow you to specify a list
of files to transfer. The normal rsync syntax allows you to specify
a list of SRC files to transfer on the command line. This patch
adds some new options to allow
38 matches
Mail list logo
