On Tue, Oct 26, 2004 at 06:55:02PM -0700, Scott Webster wrote:
> It tries to create directories higher up in the structure after
> already failing...
OK, this error can also occur when removing a directory from the
destination that already exists in the backup hierarchy. I just
checked-in a fix f
Yeah, i know. Well, when I installed 2.6.3 the error message changed
(notice that it doesn't contain the string "make_bak_dir" anymore).
Here is another snippet of the error in action. You can see that it
isn't the problem you described (where there used to be a file name
that is now a directory
On Tue, Oct 26, 2004 at 05:52:41PM -0700, Scott Webster wrote:
> and seems to be mistakenly trying to recreate the directory when
> copying another file in the same directory over?
I doubt it -- that is what 2.6.2 was doing, but not 2.6.3 -- 2.6.3 only
calls make_bak_dir() when it gets an ENOENT e
I erased that directory in that error message
(/home/swebster/fdtdtemp/temp/examples), which contained some files.
Now rsync is copying those files to the backup directory since I
specified --backup. Except that it already created the directory in
the --backup-dir directory (in this case "Tuesday
On Tue, Oct 26, 2004 at 05:07:50PM -0700, Scott Webster wrote:
> rsync: mkdir "/mnt/usbhd/Tuesday/home/swebster/fdtdtemp/temp/examples"
> failed: File exists (17)
What kind of an update is rsync trying to do when that message happens?
I finally got that message if there was a file already backed u
Yes, I realized I forgot to paste the command in after I sent the
previous email. Sorry about that.
Here it is:
rsync --stats --delete-excluded --exclude Cache/ --exclude nobackup/
--exclude Trash/ --exclude .cxoffice/ --delete --backup
--backup-dir=/mnt/usbhd/`date +%A` -a /home /mnt/usbhd/curr
On Tue, 2004-10-26 at 16:15, Wayne Davison wrote:
> On Sun, Oct 24, 2004 at 10:46:01AM -0700, Dan Stromberg wrote:
> > We're copying from 3 NFS mounts of 3 GFS volumes, into 1 NFS mount of
> > 1 Lustre volume.
>
> Since you're merging 3 sources into one destination, unless all 3
> sources have uni
On Sun, Oct 24, 2004 at 10:46:01AM -0700, Dan Stromberg wrote:
> We're copying from 3 NFS mounts of 3 GFS volumes, into 1 NFS mount of
> 1 Lustre volume.
Since you're merging 3 sources into one destination, unless all 3
sources have unique names, the unexpected copying is probably because
rsync re
On Mon, Oct 25, 2004 at 11:29:44AM -0700, Scott Webster wrote:
> Using version 2.6.3 now, which is supposed to fix bug number 1412.
> Although the frequency of the warnings seems to be reduced, now I get
> the following (slightly different) error message:
It would help if you mentioned what comma
On Tue, Oct 26, 2004 at 10:17:15AM -0400, Yasushi Okubo wrote:
> What we are having problem is that when rsync gets kicked off and
> transfers one file to the destination, this action changes ctime of
> "all" files in the same directory and sub directories on the
> destination side
Rsync only pres
Sorry again, one more thing.
We tested rsync with -a/-t option, but it does not save ctime file
attribute.
Original Message
Subject:
[Fwd: question for file attributes (atime, ctime)]
Date:
Tue, 26 Oct 2004 10:17:15 -0400
It looks like I need to elaborate further to get a feedback.
I checked the rsync source code and it is using utime() to restore
atime file attribute. It is fine to change ctime for that transferred
file in this case.
What we are having problem is that when rsync gets kicked off and
tran
12 matches
Mail list logo
