I'm catching up on a couple weeks of rsync messages, and I haven't seen
anybody explain in this thread the real problem with .nfs files and
executables. With a NFS cluster of machines (at least pre-NFSv4), a
software distribution system does have to rename executables that might be
running (as op
On 16 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
> If by sillyrename, you mean busy text files are renamed to .nfs*,
"sillyrename" is in fact the technical term for this. I am not making
it up. I'm pretty sure Callaghan's book calls it that, Sun people call
it that, and it is the term
On Tue, Jul 16, 2002 at 10:50:03AM +1000, Martin Pool wrote:
> On 15 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
>
> > The issue was that demand
> > paging would glitch from .nfs* for no good reason.
>
> That is an extremely unconvincing argument for changing rsync.
>
> > > Is it possibl
On 15 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
> The issue was that demand
> paging would glitch from .nfs* for no good reason.
That is an extremely unconvincing argument for changing rsync.
> > Is it possible to just rsync onto the NFS server, rather than onto the
> > clients? That
On Sat, Jul 13, 2002 at 10:22:29AM +1000, Martin Pool wrote:
> On 12 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
>
> > Because when we update, for example, bash, everbody's bash is going to
> > die on them if we don't keep around backups (segfault as you demand page
> > from a binary that
On Fri, 2002-07-12 at 17:01, Martin Pool wrote:
> I think the main questions are:
>
> - do people actually want all that flexibility?
>
> - is it worth starting from scratch?
>
> - is this a reasonable way to go
>
> You can see the current thoughts here:
>
> http://samba.org/~mbp/superli
On 12 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
> Because when we update, for example, bash, everbody's bash is going to
> die on them if we don't keep around backups (segfault as you demand page
> from a binary that has Mostly the Same Stuff in Different Places).
rsync creates a new fi
On 12 Jul 2002, Ben Escoto <[EMAIL PROTECTED]> wrote:
> On Thu, 2002-07-11 at 21:59, Martin Pool wrote:
> > I have been thinking about what general strategies software tools use
> > to address this problem of focus. They seem to be
>
> Haven't the rsync people already evalutated some of these op
On Thu, 2002-07-11 at 21:59, Martin Pool wrote:
> I have been thinking about what general strategies software tools use
> to address this problem of focus. They seem to be
Haven't the rsync people already evalutated some of these options? I
think I remember seeing "plugins" as one of the planne
On Fri, Jul 12, 2002 at 02:59:11PM +1000, Martin Pool wrote:
> On 11 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
>
> > > I don't get what you are doing. Where did these insecure
> > > suid root files come from in the first place?
> >
> > Have you ever read bugtraq on a regular basis? Th
On 11 Jul 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
> > I don't get what you are doing. Where did these insecure
> > suid root files come from in the first place?
>
> Have you ever read bugtraq on a regular basis? They're coming out of
> the woodwork.
Another question would be, why do yo
On Tue, Jul 09, 2002 at 12:20:09PM -0600, Robert Weber wrote:
> > > This brings up an issue that I believe can be solved in a simpler way than
> > > with brute force C code. I suspect some of you will cringe when you hear
> > > this, but a taintperl log parsing program would be best for this. rs
On 8 Jul 2002, Dave Dykstra <[EMAIL PROTECTED]> wrote:
> The idea of the rsync client executing programs has been descussed before
> and rejected because it could easily be done by an external program if
> rsync simply passes it filenames. The only case I can see for having rsync
> execute progr
On Tue, Jul 09, 2002 at 02:36:22PM -0700, jw schultz wrote:
> On Tue, Jul 09, 2002 at 11:03:25AM -0700, Dan Stromberg wrote:
> > On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> > > The default behavior should not modify files. The general
> > > purpose is to have the copies be the s
On Tue, Jul 09, 2002 at 05:05:31PM -0600, [EMAIL PROTECTED] wrote:
> I vote for the consistent, complete log format as a solution to this sort
> of thing, and those who need to take non-rsync related actions based on
> what rsync did can write their own applications to do so.
>
> People keep co
> That is something that I'm working on with my rZync application. It
> implements a new protocol that can begin transferring files as soon as
> the first directory has been transferred and compared. The program is
> not yet ready for someone with millions of files to test, though
Wayne, I loo
On Mon, 8 Jul 2002, Eric Horst wrote:
> Not to mention, is it a real long-term goal is to redesign rsync to deal
> with large numbers of files by not building the entire file list up front?
That is something that I'm working on with my rZync application. It
implements a new protocol that can beg
I vote for the consistent, complete log format as a solution to this sort
of thing, and those who need to take non-rsync related actions based on
what rsync did can write their own applications to do so.
People keep coming up with some particular thing they need done for their
own application,
On Tue, Jul 09, 2002 at 11:03:25AM -0700, Dan Stromberg wrote:
> On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> > The default behavior should not modify files. The general
> > purpose is to have the copies be the same as the original.
> > A general --chmod or --pmask option might b
Dan Stromberg wrote:
>
> On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> > The default behavior should not modify files. The general
> > purpose is to have the copies be the same as the original.
> > A general --chmod or --pmask option might be acceptable for
> > modifying the perm
> > This brings up an issue that I believe can be solved in a simpler way than
> > with brute force C code. I suspect some of you will cringe when you hear
> > this, but a taintperl log parsing program would be best for this. rsync
> > could generate a verbose log file that is not human readable
On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> The default behavior should not modify files. The general
> purpose is to have the copies be the same as the original.
> A general --chmod or --pmask option might be acceptable for
> modifying the permissions flags but would need to be
On Tue, Jul 09, 2002 at 09:37:28AM -0600, Robert Weber wrote:
> >
> > > never seen a file created with a newline in the filename
> > > (except, perhaps as a test). The newline in filename issue
> >
> > And in security exploits :-) Given a newline-based format, one *must*
> > quote or deny newl
>
> > never seen a file created with a newline in the filename
> > (except, perhaps as a test). The newline in filename issue
>
> And in security exploits :-) Given a newline-based format, one *must*
> quote or deny newlines in filenames, not assume they're rare. (No
> obvious reason not to u
> never seen a file created with a newline in the filename
> (except, perhaps as a test). The newline in filename issue
And in security exploits :-) Given a newline-based format, one *must*
quote or deny newlines in filenames, not assume they're rare. (No
obvious reason not to use URL-style %
On Mon, Jul 08, 2002 at 05:40:58PM -0400, Lenny Foner wrote:
> Date: Mon, 8 Jul 2002 21:18:18 +0800
> From: Adrian Ho <[EMAIL PROTECTED]>
>
> If the sender's/receiver's cwd is guaranteed to be the root of the
> corresponding rsync'd hierarchies, then yes, relative paths would
>
Date: Mon, 8 Jul 2002 21:18:18 +0800
From: Adrian Ho <[EMAIL PROTECTED]>
If the sender's/receiver's cwd is guaranteed to be the root of the
corresponding rsync'd hierarchies, then yes, relative paths would
suffice.
>
> UPDATEfoo/
> CREATEfoo/bar1
> UP
On Mon, Jul 08, 2002 at 05:56:57PM +1000, Martin Pool wrote:
> Any thoughts on whether this should go in? I can see arguments either
> way. It seems like we ought to think about whether it would be better
> to do it as part of a generalized --chmod or --chmod-backup facility.
>
>
>
> On 21 Ju
On Mon, Jul 08, 2002 at 08:52:29AM -0700, Eric Horst wrote:
>
> Hi, I'm new around here and thought I'd join the discussion. Hope that's
> ok.
>
> > I'm inclined to push for more flexibility with:
> >
> > --post-process=
> > Runs on the receiver just before rsync exits.
> > is passe
The idea of the rsync client executing programs has been descussed before
and rejected because it could easily be done by an external program if
rsync simply passes it filenames. The only case I can see for having rsync
execute programs is in the daemon; that was once approved in principle but
no
Hi, I'm new around here and thought I'd join the discussion. Hope that's
ok.
> I'm inclined to push for more flexibility with:
>
> --post-process=
> Runs on the receiver just before rsync exits.
> is passed a list of fully-qualified pathnames on
> stdin (one per line) that have
On Mon, Jul 08, 2002 at 09:18:18PM +0800, Adrian Ho wrote:
> On Mon, Jul 08, 2002 at 03:52:16AM -0700, jw schultz wrote:
> > Also the path should not be fully qualified but instead should match
> > that of the commandline with cwd the same as the rsync launch.
>
> If the sender's/receiver's cwd i
On Mon, Jul 08, 2002 at 03:52:16AM -0700, jw schultz wrote:
> However, if it lists created, modified and deleted files it will need
> to differentiate. It should instead list the files and the action.
Well, yeah, that's probably more useful in general. 8-)
> Also the path should not be fully q
On Mon, Jul 08, 2002 at 06:01:48PM +0800, Adrian Ho wrote:
> On Mon, Jul 08, 2002 at 05:37:13PM +0800, Adrian Ho wrote:
> > I'm inclined to push for more flexibility with:
>
> Actually, make that:
>
> --post-send=
> --post-recv=
> Runs on the sender/receiver just before rsync exits.
>
On Mon, Jul 08, 2002 at 05:37:13PM +0800, Adrian Ho wrote:
> I'm inclined to push for more flexibility with:
Actually, make that:
--post-send=
--post-recv=
Runs on the sender/receiver just before rsync exits.
is passed a list of fully-qualified pathnames on
stdin (one per line)
On Mon, Jul 08, 2002 at 05:56:57PM +1000, Martin Pool wrote:
> Any thoughts on whether this should go in? I can see arguments either
> way. It seems like we ought to think about whether it would be better
> to do it as part of a generalized --chmod or --chmod-backup facility.
I'm inclined to pu
Any thoughts on whether this should go in? I can see arguments either
way. It seems like we ought to think about whether it would be better
to do it as part of a generalized --chmod or --chmod-backup facility.
--
Martin
On 21 Jun 2002, Dan Stromberg <[EMAIL PROTECTED]> wrote:
> Included bel
37 matches
Mail list logo
