Re: read error produces null-byte-filled destination file
On Mon, May 10, 2004 at 02:45:15PM -0700, Todd Stansell wrote:
Subsequent rsyncs will succeed without any errors as long as the -c
option isn't used. You'd never know the file was corrupted, since the
size and timestamp are both correct on the destination file.
It's pretty easy to at least fix this file-is-up-to-date deception. The
appended patch changes rsync to send a bogus whole-file-checksum to the
receiver if there was an error reading the file. This will cause the
receiver to ask for a resend (which will handle the case where the read
error was temporary, such as the file getting shorter during the
transfer). If the resend fails, the file's time is not preserved, thus
marking it as not being updated correctly (at least to rsync). The file
would still be full of nulls, however.
What do you think? Rsync has always moved a finished file into place,
even if it fails the full-file checksum. I'm wondering if this is
really a good idea. Perhaps that should only occur if the --partial
flag was specified (in which case we're telling rsync that we'll accept
a not-quite-finished file if it helps the next transfer to be more
optimal).
..wayne..
--- cleanup.c 27 Jan 2004 08:14:33 - 1.21
+++ cleanup.c 11 May 2004 20:20:10 -
@@ -116,7 +116,7 @@ void _exit_cleanup(int code, const char
if (cleanup_buf) unmap_file(cleanup_buf);
if (cleanup_fd1 != -1) close(cleanup_fd1);
if (cleanup_fd2 != -1) close(cleanup_fd2);
- finish_transfer(cleanup_new_fname, fname, cleanup_file);
+ finish_transfer(cleanup_new_fname, fname, cleanup_file, 0);
}
io_flush(FULL_FLUSH);
if (cleanup_fname)
--- generator.c 5 May 2004 17:15:03 - 1.81
+++ generator.c 11 May 2004 20:20:10 -
@@ -351,7 +351,8 @@ void recv_generator(char *fname, struct
* right place -- no further action
* required. */
if (strcmp(lnk,file-u.link) == 0) {
- set_perms(fname,file,st,1);
+ set_perms(fname, file, st,
+ PERMS_REPORT);
return;
}
}
@@ -391,7 +392,7 @@ void recv_generator(char *fname, struct
rprintf(FINFO,%s\n,fname);
}
} else {
- set_perms(fname,file,st,1);
+ set_perms(fname, file, st, PERMS_REPORT);
}
return;
}
@@ -473,7 +474,7 @@ void recv_generator(char *fname, struct
if (skip_file(fname, file, st)) {
if (fnamecmp == fname)
- set_perms(fname,file,st,1);
+ set_perms(fname, file, st, PERMS_REPORT);
return;
}
--- match.c 3 Jan 2004 19:28:03 - 1.60
+++ match.c 11 May 2004 20:20:11 -
@@ -322,6 +322,9 @@ void match_sums(int f, struct sum_struct
}
sum_end(file_sum);
+ /* If we had a read error, send a bad checksum. */
+ if (buf buf-status != 0)
+ file_sum[0]++;
if (verbose 2)
rprintf(FINFO,sending file_sum\n);
--- proto.h 22 Apr 2004 09:58:09 - 1.189
+++ proto.h 11 May 2004 20:20:11 -
@@ -192,9 +192,10 @@ int recv_files(int f_in,struct file_list
void free_sums(struct sum_struct *s);
int delete_file(char *fname);
int set_perms(char *fname,struct file_struct *file,STRUCT_STAT *st,
- int report);
+ int flags);
void sig_int(void);
-void finish_transfer(char *fname, char *fnametmp, struct file_struct *file);
+void finish_transfer(char *fname, char *fnametmp, struct file_struct *file,
+int ok_to_set_time);
const char *who_am_i(void);
void read_sum_head(int f, struct sum_struct *sum);
void send_files(struct file_list *flist, int f_out, int f_in);
--- receiver.c 27 Apr 2004 19:51:33 - 1.76
+++ receiver.c 11 May 2004 20:20:11 -
@@ -467,7 +467,7 @@ int recv_files(int f_in,struct file_list
if (verbose 2)
rprintf(FINFO,renaming %s to %s\n,fnametmp,fname);
- finish_transfer(fname, fnametmp, file);
+ finish_transfer(fname, fnametmp, file, recv_ok);
cleanup_disable();
--- rsync.c 23 Mar 2004 16:16:15 - 1.135
+++ rsync.c 11 May 2004 20:20:12 -
@@ -123,7 +123,7 @@ int delete_file(char *fname)
}
int set_perms(char *fname,struct file_struct *file,STRUCT_STAT *st,
- int report)
+ int flags)
{
int updated = 0;
STRUCT_STAT st2;
@@ -140,8 +140,10 @@ int set_perms(char *fname,struct file_st
st = st2;
}
- if
Re: read error produces null-byte-filled destination file
On Tue, May 11, 2004 at 01:39:24PM -0700, Wayne Davison wrote: It's pretty easy to at least fix this file-is-up-to-date deception. While this fix may be useful to some people, I'd much rather wait to see a real fix such that read errors on the sending side doesn't result in a corrupt file on the destination. We only ran into this in an edge case and have taken steps to prevent this as much as possible in the future. Thanks, Todd -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: read error produces null-byte-filled destination file
--On Tuesday, May 11, 2004 13:39:24 -0700 Wayne Davison [EMAIL PROTECTED] wrote: What do you think? Rsync has always moved a finished file into place, even if it fails the full-file checksum. I'm wondering if this is really a good idea. Perhaps that should only occur if the --partial flag was specified (in which case we're telling rsync that we'll accept a not-quite-finished file if it helps the next transfer to be more optimal). Yes - rsync should _not_ use known-bad copies of files unless --partial has been specified. -- Carson -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync-2.6.2: NFS clients confused after an rsync
On Tue, 11 May 2004, Wayne Davison [EMAIL PROTECTED] wrote: On Tue, May 11, 2004 at 01:48:33PM -0400, Brian Childs wrote: Yes. Without the -b, it doesn't happen. OK, I think I know why now: without -b the old inode goes away, and thus NFS gets some indication that a change has occurred in the data it has cached. I disagree. I think Brian had it right: On Thu, 6 May 2004, Brian Childs [EMAIL PROTECTED] wrote: What I think is happening: -- * testfile is updated in place, so the mtime of testpath isn't udpated. * The nfs client is caching the mtime of testpath * The seconds rsync modifies the contents of testpath, but when finished, it resets the mtime on testpath * The client believes it's cache is valid, so I doesn't refresh, and therefore it misses the update Rsync is doing a Bad Thing when it creates in a directory a new file (the backup file) that is not part of the source content, and then *changes the mtime* of the directory back to its source content value(!). It should be left in its modified non-rsync'ed state since the target directory content no longer matches the source content. Anyone who uses a --backup option is subverting the 'exact' directory replication that rsync normally does, so I think that never preserving directory modtimes is appropriate for --backup. I think Brian's very simple patch (refined version posted 5/11) using an extra set_modtime() arg and testing for make_backup is the right fix. That fix could be refined even further by also checking for any specified backup-dir. If one was given, then it will be OK to always restore mod times in the original target location since no backup files are being created there. -- John Van Essen Univ of MN Alumnus [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: read error produces null-byte-filled destination file
On Tue, May 11, 2004 at 09:42:15PM -0400, Carson Gaspar wrote: Yes - rsync should _not_ use known-bad copies of files unless --partial has been specified. I'd have to agree with Carson 100%. Of the files that appear on the destination, I'd expect them all to be 100% accurate or fail to get created. Todd -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
possible bug with exclude/exclude-from
Hi While trying to back up my homedir, i found what looks like a bug: from /home, i do: rsync -CWavP --delete --delete-excluded \ --exclude=.phoenix/default/*/Cache/ \ --exclude-from=rsync-excludes \ myusername/ targetserver:/backup/myusername/ rsync-excludes contains (without [] lines): [start] #comment **.xvpics** *.swp [end] This works as expected, the phoenix cache dir is excluded, xvpics and .swp files as well. Now, if i try the the same except the .phoenix stuff moved to the exclude file: rsync -CWavP --delete --delete-excluded \ --exclude-from=rsync-excludes \ myusername/ targetserver:/backup/roth/ rsync-excludes now contains (again without []): [start] #comment .phoenix/default/*/Cache/ **.xvpics** *.swp [end] This way, the phoenix cache dir gets transfered. The other two excludes still work fine. rsync version is: rsync version 2.6.2 protocol version 28 I can provide more details if needed. greets, t. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsync output -vv differs with dry-run option
I'm trying to figure out if a file has changed since the last rsync call. I use the following command line: rsync -cvv /mnt/xxx/vol1/dbase/100/kunden.dbf /mnt/label | grep ^total: | sed -e 's/.* data=//' This gives a 0 if the file is unchanged and the file size if the file has changed. Adding the dry-run option n to the command line always gives a 0. I wonder if this is a expected behaviour? -- Claas Hilbrecht http://www.jucs-kramkiste.de -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync output -vv differs with dry-run option
The dry run was successful, and transferred 0 bytes. The dry run is for a quick check, and will show what objects, if any, would be transferred in a real run, not exactly how many bytes would be transferred. Perhaps a --write-batch in a dry run could create the batch files, and you could just wc them. Tim Conway Unix System Administration Contractor - IBM Global Services desk:3032734776 [EMAIL PROTECTED] I'm trying to figure out if a file has changed since the last rsync call. I use the following command line: rsync -cvv /mnt/xxx/vol1/dbase/100/kunden.dbf /mnt/label | grep ^total: | sed -e 's/.* data=//' This gives a 0 if the file is unchanged and the file size if the file has changed. Adding the dry-run option n to the command line always gives a 0. I wonder if this is a expected behaviour? -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync-2.6.2: NFS clients confused after an rsync [PATCH included]
On Fri, May 07, 2004 at 11:18:46AM -0400, Brian Childs wrote:
As a response to my original post, here's a patch that implements my
proposed solution.
I've tested it, and it fixes the problem, but I'm afraid there may be
some hidden consequences of doing this.
I've refined my patch to eliminate the extra 'lstat'. It makes it a
larger patch, but I believe it's correct and more efficient.
I kept the check for IS_SDIR in the set_modtime function because I
didn't want to push that responsibility to the caller of the function.
That's a sure way for this bug to return.
The 'backup dir' code sets the modtime on newly created directories
only. I've opted to keep that in the code. A new dir can't be in
anyones dentry cache.
Anyway, here's the new patch.
Thanks,
Brian
diff -x '*~' -x '*.o' -ur rsync-2.6.2/backup.c rsync-2.6.2-rentec/backup.c
--- rsync-2.6.2/backup.c2004-03-13 15:18:03.0 -0500
+++ rsync-2.6.2-rentec/backup.c 2004-05-11 09:03:15.0 -0400
@@ -101,7 +101,7 @@
make_bak_dir stat %s failed: %s\n,
full_fname(rel), strerror(errno));
} else {
- set_modtime(fullpath, st.st_mtime);
+ set_modtime(fullpath, st.st_mtime, st.st_mode);
do_lchown(fullpath, st.st_uid, st.st_gid);
do_chmod(fullpath, st.st_mode);
}
diff -x '*~' -x '*.o' -ur rsync-2.6.2/proto.h rsync-2.6.2-rentec/proto.h
--- rsync-2.6.2/proto.h 2004-04-22 05:58:09.0 -0400
+++ rsync-2.6.2-rentec/proto.h 2004-05-11 09:01:28.0 -0400
@@ -242,7 +242,7 @@
void print_child_argv(char **cmd);
void out_of_memory(char *str);
void overflow(char *str);
-int set_modtime(char *fname, time_t modtime);
+int set_modtime(char *fname, time_t modtime, mode_t mode);
int create_directory_path(char *fname, int base_umask);
int copy_file(char *source, char *dest, mode_t mode);
int robust_unlink(char *fname);
diff -x '*~' -x '*.o' -ur rsync-2.6.2/rsync.c rsync-2.6.2-rentec/rsync.c
--- rsync-2.6.2/rsync.c 2004-03-23 11:16:15.0 -0500
+++ rsync-2.6.2-rentec/rsync.c 2004-05-11 09:03:38.0 -0400
@@ -144,7 +144,7 @@
cmp_modtime(st-st_mtime, file-modtime) != 0) {
/* don't complain about not setting times on directories
* because some filesystems can't do it */
- if (set_modtime(fname,file-modtime) != 0
+ if (set_modtime(fname,file-modtime,file-mode) != 0
!S_ISDIR(st-st_mode)) {
rprintf(FERROR, failed to set times on %s: %s\n,
full_fname(fname), strerror(errno));
diff -x '*~' -x '*.o' -ur rsync-2.6.2/util.c rsync-2.6.2-rentec/util.c
--- rsync-2.6.2/util.c 2004-04-27 15:59:37.0 -0400
+++ rsync-2.6.2-rentec/util.c 2004-05-11 09:00:45.0 -0400
@@ -124,12 +124,18 @@
-int set_modtime(char *fname, time_t modtime)
+int set_modtime(char *fname, time_t modtime, mode_t mode)
{
extern int dry_run;
+ extern int make_backups;
+
if (dry_run)
return 0;
+ if(make_backups S_ISDIR(mode)) {
+ return 0;
+ }
+
if (verbose 2) {
rprintf(FINFO, set modtime of %s to (%ld) %s,
fname, (long) modtime,
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: rsync output -vv differs with dry-run option
I've noticed a difference between the dry-run and normal execution as well using /usr/local/bin/rsync -avrnz --exclude-from=/davet/rsync.webmstr1 --stats [EMAIL PROTECTED]::webmstr1 /export/home/webmstr. I'm not clear why, but it appears as if the dry run method, using -n, is not reporting all the files that are actually effected. I'm basing this on the report that rsync provides and am wondering if the -n only checks for files that are actually going to be transferred while the -avrn report includes empty diretories that will be created on the client side? My two cents... Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Claas Hilbrecht Sent: Tuesday, May 11, 2004 7:49 AM To: [EMAIL PROTECTED] Subject: rsync output -vv differs with dry-run option I'm trying to figure out if a file has changed since the last rsync call. I use the following command line: rsync -cvv /mnt/xxx/vol1/dbase/100/kunden.dbf /mnt/label | grep ^total: | sed -e 's/.* data=//' This gives a 0 if the file is unchanged and the file size if the file has changed. Adding the dry-run option n to the command line always gives a 0. I wonder if this is a expected behaviour? -- Claas Hilbrecht http://www.jucs-kramkiste.de -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: rsync output -vv differs with dry-run option
Correction: The options I'm comparing are -avr and -avrn. I meant that I'm getting a different report with the -n compared to without -n. Sorry... Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 11, 2004 11:06 AM To: [EMAIL PROTECTED] Subject: RE: rsync output -vv differs with dry-run option I've noticed a difference between the dry-run and normal execution as well using /usr/local/bin/rsync -avrnz --exclude-from=/davet/rsync.webmstr1 --stats [EMAIL PROTECTED]::webmstr1 /export/home/webmstr. I'm not clear why, but it appears as if the dry run method, using -n, is not reporting all the files that are actually effected. I'm basing this on the report that rsync provides and am wondering if the -n only checks for files that are actually going to be transferred while the -avrn report includes empty diretories that will be created on the client side? My two cents... Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Claas Hilbrecht Sent: Tuesday, May 11, 2004 7:49 AM To: [EMAIL PROTECTED] Subject: rsync output -vv differs with dry-run option I'm trying to figure out if a file has changed since the last rsync call. I use the following command line: rsync -cvv /mnt/xxx/vol1/dbase/100/kunden.dbf /mnt/label | grep ^total: | sed -e 's/.* data=//' This gives a 0 if the file is unchanged and the file size if the file has changed. Adding the dry-run option n to the command line always gives a 0. I wonder if this is a expected behaviour? -- Claas Hilbrecht http://www.jucs-kramkiste.de -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: possible bug with exclude/exclude-from
I created a pretty complex exclude file recently and it took a lot of help from the forum. But, I learned that using +/- in front of each line is very helpful. The order is also very important. Try the following exclude files. [start] - phoenix/default/*/Cache/* (not sure how rsync handles dot files, try removing the dot in front of pheonix) - **.xvpics** - *.swp [end] You should be able to simplify if there are no other /Cache/ dirs you want to copy. [start] - /Cache/ - **.xvpics** - *.swp [end] Also, try changing the order. I found in my exclude that when an exclude entry was ignored it was due to the order and directories should come after files. [start] **.xvpics** *.swp .phoenix/default/*/Cache/ [end] You may need to combine some of the other suggestions in a trial and error test. But try changing the order first! Hope that helps, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tobias Roth Sent: Tuesday, May 11, 2004 5:52 AM To: [EMAIL PROTECTED] Subject: possible bug with exclude/exclude-from Hi While trying to back up my homedir, i found what looks like a bug: from /home, i do: rsync -CWavP --delete --delete-excluded \ --exclude=.phoenix/default/*/Cache/ \ --exclude-from=rsync-excludes \ myusername/ targetserver:/backup/myusername/ rsync-excludes contains (without [] lines): [start] #comment **.xvpics** *.swp [end] This works as expected, the phoenix cache dir is excluded, xvpics and .swp files as well. Now, if i try the the same except the .phoenix stuff moved to the exclude file: rsync -CWavP --delete --delete-excluded \ --exclude-from=rsync-excludes \ myusername/ targetserver:/backup/roth/ rsync-excludes now contains (again without []): [start] #comment .phoenix/default/*/Cache/ **.xvpics** *.swp [end] This way, the phoenix cache dir gets transfered. The other two excludes still work fine. rsync version is: rsync version 2.6.2 protocol version 28 I can provide more details if needed. greets, t. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
cwrsync strange path in error message
Hi, I am running cwrsync. 2004/05/11 [93] rsync error: some files could not be transferred (code 23) at /home/lapo/packaging/tmp/rsync-2.5.7/main.c(383) I am uncertain as to what this path statement is about in the above error message. /home/lapo/packaging/tmp/rsync-2.5.7/main.c(383) Thanks, Pat -- Patricia Palumbo DuBois King, Inc. [EMAIL PROTECTED] 802-728-4113 | ext 322 fax: 802-728-3035 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Would this patch be useful...
I am considering a patch that would exclude compressing a given list of file extensions when the -z option is used. Users may want to use -z, but not want to try to compress .gz, .jpg, .mp3, etc. type files. Rsyncd has this feature with it's dont compress option, but I think many users are using rsync over ssh and therefore do not have this functionality available to them. The way my test code works is by modifying the set_compression() function in token.c and using the wildmatch() function, exactly like rsyncd's dont compress option is doing now. If this seems useful, I want to receive input on how to implement the user-interface. I was thinking about two command line options, --dont-compress and --dont-compress-from. This is what it would look like: rsync -z --dont-compress=*.mp3 *.gz . However, since this list could be very long, you would also have: rsync -z --dont-compress-from=/etc/rsync/already_compressed.txt where the already_compressed.txt would have a list of extensions not to compress. Another option, is to have --dont-compress and --dont-compress-from use rsync's Exclude Patterns, but I have not studied this code and do not know how much harder this would be to implement. Any thought? -John -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--backup-dir and daemon mode
Is it possible to use --backup-dir= with a daemon mode target? I have been attempting to use --backup and --backup-dir= with a daemon mode server I use as target for an rsync command that pushes from the server needing backing up, and have met with no luck - I keep getting broken pipe errors, and attempts to create directories like [EMAIL PROTECTED]::backup/backup on the server doing the rsyncing's own filesystem. If anybody's ever tried doing this kind of thing, your experience would be very helpful. Thanks! Jim Salter -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: possible bug with exclude/exclude-from
On Tue, May 11, 2004 at 11:51:32AM +0200, Tobias Roth wrote: [start] #comment .phoenix/default/*/Cache/ **.xvpics** *.swp [end] I'd recommend checking the phoenix line for trailing spaces. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync-2.6.2: NFS clients confused after an rsync
On Tue, May 11, 2004 at 10:01:48AM -0700, Wayne Davison wrote: On Thu, May 06, 2004 at 06:21:55PM -0400, Brian Childs wrote: rm -f /tmp/testpath/* $HOME/testpath/* #Prime it echo some data /tmp/testpath/testfile sleep 1 rsync -a /tmp/testpath/ $HOME/testpath/ ssh $otherbox ls -li $HOME/testpath #Break it echo additional data /tmp/testpath/testfile sleep 1 rsync -a -b /tmp/testpath/ $HOME/testpath/ ssh $otherbox ls -li $HOME/testpath Do you actually need to use the -b option for the breakage to happen? Yes. Without the -b, it doesn't happen. In the output you show, not only is the new testfile~ not yet found, but the extra data in testfile is not seen (including showing the wrong inode). Since rsync isn't actually updating any files in-place, the file gets a new inode while keeping the directory time unchanged, so that may be enough to confuse NFS. I believe that's exactly what's happening. rsync is in effect spoofing the nfs clients dentry cache. I had been considering making the preservation of directory times an optional occurance with rsync. The appended patch implements this. Comments? I'll try it Thanks, Brian -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync-2.6.2: NFS clients confused after an rsync
On Tue, May 11, 2004 at 01:48:33PM -0400, Brian Childs wrote: Yes. Without the -b, it doesn't happen. OK, I think I know why now: without -b the old inode goes away, and thus NFS gets some indication that a change has occurred in the data it has cached. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: cwrsync strange path in error message
That now makes sense.. Thanks Tim! Patricia That's where main.c was when the binary was compiled. It's telling you that if you took the same source code and looked at line 383 of main.c, you would see the line that generated that error 23. Tim Conway Unix System Administration Contractor - IBM Global Services desk:3032734776 [EMAIL PROTECTED] 2004/05/11 [93] rsync error: some files could not be transferred (code 23) at /home/lapo/packaging/tmp/rsync-2.5.7/main.c(383) -- Patricia Palumbo DuBois King, Inc. [EMAIL PROTECTED] 802-728-4113 | ext 322 fax: 802-728-3035 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: read error produces null-byte-filled destination file
On Mon, May 10, 2004 at 02:45:15PM -0700, Todd Stansell wrote: 2.6.2 now produces an error message, but still also produces the corrupted destination file. Yes, starting with 2.6.0 we at least get an error message that something went wrong. However, it would be much better if the receiver did not update the file as if it were transferred correctly. I'll need to look at the protocol and see if there is a way to convey this information from the sender to the receiver (or add a way). ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync-2.6.2: NFS clients confused after an rsync
On Tue, May 11, 2004 at 11:22:27AM -0700, Wayne Davison wrote: On Tue, May 11, 2004 at 01:48:33PM -0400, Brian Childs wrote: Yes. Without the -b, it doesn't happen. OK, I think I know why now: without -b the old inode goes away, and thus NFS gets some indication that a change has occurred in the data it has cached. The patch works great. I was also able to recreate the bug using the new -d option. Brian -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
CVS update: rsync
Date: Tue May 11 17:25:16 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv6110 Modified Files: flist.c Log Message: Got rid of an unused extern. Revisions: flist.c 1.220 = 1.221 http://www.samba.org/cgi-bin/cvsweb/rsync/flist.c.diff?r1=1.220r2=1.221 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Tue May 11 19:46:56 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv8181 Modified Files: fileio.c Log Message: Use memset() to initialize a new map_struct. Revisions: fileio.c1.11 = 1.12 http://www.samba.org/cgi-bin/cvsweb/rsync/fileio.c.diff?r1=1.11r2=1.12 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Tue May 11 19:53:16 2004 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv9095 Modified Files: sender.c Log Message: In send_files(), changed the name of the map_struct variable from buf to mbuf (so that it wouldn't be so similar to the buff variable nor use a name that is more typically a char* buffer). Revisions: sender.c1.38 = 1.39 http://www.samba.org/cgi-bin/cvsweb/rsync/sender.c.diff?r1=1.38r2=1.39 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
