On Fri, Apr 20, 2007 at 12:25:55AM -0400, Chris Lewis wrote:
> sh-3.1# ./rsync -x / /zorilla/foo
> skipping directory /.
You need to specify either -r or -d to copy a directory.
..wayne..
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: ht
I checked the archives and bug lists, and didn't see this. Or rather, I
saw someone report it, but it was backrev and a "non-standard" release,
so that was considered out of bounds.
I'm running on Ubuntu Dapper Drake, and first experienced this problem
trying to do rsync backups via backuppc. I
Wayne Davison wrote:
Good point. I'm going to include the ability to transfer a > 4-byte
time_t value for protocol 30. We'll need to consider what should be
done if a value is too large for the destination system to handle.
Emit a WARNING and set to MAX_TIME_T on the destination? It's either
Wayne Davison wrote:
On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
I use rsync as a backup tool (via rsnapshot) and noticed that it had a
problem with a couple of files which had timestamps way off in the
future.
That's a unix-time limitation. The current timestamp resolution c
> "Transferring" refers specifically to copying the *data* of a regular
> file from sender to receiver and is only one of several things that
> rsync can do to a file. The others: rsync can "locally create" files
> (usually only non-regular files), hard-link them, delete them, and
> "tweak" their
On Tue, 17 Apr 2007, Wayne Davison wrote:
On Mon, Apr 16, 2007 at 01:44:29PM -0700, [EMAIL PROTECTED] wrote:
The strange thing is that _some_ files are being deleted.. just a few, and
obviously not nearly enough.
Are you checking for errors? Does rsync get an I/O error and stop
deleting? (
On Thu, Apr 19, 2007 at 07:19:00PM +0100, Jon Burgess wrote:
> The particular problem I see where the timestamps 1940 != 2076 is due to
> a 64 bit time_t. On such platforms, increasing the modtime protocol
> entity from 4 to 8 bytes is sufficient to fix this.
Good point. I'm going to include the
On 4/19/07, C Sights <[EMAIL PROTECTED]> wrote:
After reading what you both have said, and throwing in some things from
previous knowledge, it seems as though what rsync does can be broken up into
a number pieces.
[...]
It might make the rsync manual more understandable if the long options were
On Thu, 2007-04-19 at 10:30 -0700, Wayne Davison wrote:
> On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> > I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> > problem with a couple of files which had timestamps way off in the
> > future.
>
> That's a unix-tim
On Thu, 2007-04-19 at 10:30 -0700, Wayne Davison wrote:
> On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> > I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> > problem with a couple of files which had timestamps way off in the
> > future.
>
> That's a unix-tim
On Thu, Apr 19, 2007 at 05:20:59PM +0100, Jon Burgess wrote:
> I use rsync as a backup tool (via rsnapshot) and noticed that it had a
> problem with a couple of files which had timestamps way off in the
> future.
That's a unix-time limitation. The current timestamp resolution can't
represent anyt
Carson,
My mistake- read "SSL", immediately started thinking "ssh",
and issues there. No excuse.
So- my comments aren't applicable to the SSL-for-real discussion -
apologies to the list.
(Aside: the issues with ssh are not about modifying TCP buffers.
They are about a fixed-size ssh-
I use rsync as a backup tool (via rsnapshot) and noticed that it had a
problem with a couple of files which had timestamps way off in the
future. You can reproduce the problem quite simply:
$ touch -t 207608011200 foo
$ rsync -a foo bar
$ ls -l foo bar
-rw-rw-r-- 1 jburgess jburgess 0 Jun 26 1940
13 matches
Mail list logo
