Re: Rsync itemizing "t" (should be "T") when lutimes fails on recreated symlink
On Mon, 2008-03-10 at 21:44 -0700, Wayne Davison wrote: > On Mon, Mar 10, 2008 at 12:23:15AM -0400, Matt McCutchen wrote: > > When rsync recreates a destination symlink to update its target path, > > rsync will fail to preserve the time, but it nevertheless itemizes "t". > > This is now fixed in the git repository along with a couple other > glitches that I turned up in the itemized output. Nice! It works! I see you also converted the non-symlink itemize condition to a ?:, which I had been thinking of proposing. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Improve --help descriptions of --*-dels options.
- --backup-dir-dels uses DIR, not the "current directory". - State the --suffix-dels default correctly. --- More work on backup-dir-dels... options.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/options.c b/options.c index ed21704..0abc1ca 100644 --- a/options.c +++ b/options.c @@ -330,8 +330,8 @@ void usage(enum logcode F) rprintf(F," -b, --backupmake backups (see --suffix & --backup-dir)\n"); rprintf(F," --backup-dir=DIRmake backups into hierarchy based in DIR\n"); rprintf(F," --suffix=SUFFIX set backup suffix (default %s w/o --backup-dir)\n",BACKUP_SUFFIX); - rprintf(F," --backup-dir-dels make backups of removed files into current dir\n"); - rprintf(F," --suffix-dels=SUFFIXset removed-files suffix (defaults to --suffix)\n"); + rprintf(F," --backup-dir-dels=DIR backup removed files into hierarchy based in DIR\n"); + rprintf(F," --suffix-dels=SUFFIXset removed-files suffix (def. --suffix w/o b-d-d)\n"); rprintf(F," -u, --updateskip files that are newer on the receiver\n"); rprintf(F," --inplace update destination files in-place (SEE MAN PAGE)\n"); rprintf(F," --appendappend data onto shorter files\n"); -- 1.5.4.3.193.g6dd0e -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Comment an obscure bit of code that sets the --suffix-dels default.
--- More work on backup-dir-dels... options.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/options.c b/options.c index 459ad58..ed21704 100644 --- a/options.c +++ b/options.c @@ -1479,6 +1479,11 @@ int parse_arguments(int *argc_p, const char ***argv_p, int frommain) backup_suffix); return 0; } + /* --suffix-dels defaults to --suffix, or empty for a client given an +* explicit --backup-dir-dels (just as --suffix defaults to empty when +* a --backup-dir is given). The second case does not apply to the +* server for consistency with server_options, which sends --suffix-dels +* to the server iff it differs from --suffix. */ if (!backup_suffix_dels) backup_suffix_dels = backup_dir_dels && !am_server ? "" : backup_suffix; backup_suffix_dels_len = strlen(backup_suffix_dels); -- 1.5.4.3.193.g6dd0e -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Protect files ending with --suffix-dels as well as --suffix.
---
More work on backup-dir-dels...
options.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/options.c b/options.c
index 3dd65fb..459ad58 100644
--- a/options.c
+++ b/options.c
@@ -1534,6 +1534,10 @@ int parse_arguments(int *argc_p, const char ***argv_p,
int frommain)
snprintf(err_buf, sizeof err_buf,
"--suffix-dels cannot be a null string without
--backup-dir-dels\n");
return 0;
+ } else if (make_backups && delete_mode && !delete_excluded &&
!am_server) {
+ snprintf(backup_dir_dels_buf, sizeof backup_dir_dels_buf,
+ "P *%s", backup_suffix_dels);
+ parse_rule(&filter_list, backup_dir_dels_buf, 0, 0);
}
if (make_backups && !backup_dir) {
--
1.5.4.3.193.g6dd0e
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Make make_backup switch on backup_dir_dels, not backup_dir, for deletions.
---
This should fix the problem with --backup-dir-dels not working by
itself.
backup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/backup.c b/backup.c
index d2a7622..ea53306 100644
--- a/backup.c
+++ b/backup.c
@@ -347,7 +347,7 @@ static int keep_backup(const char *fname)
/* main backup switch routine */
int make_backup(const char *fname)
{
- if (backup_dir)
+ if (deleting ? backup_dir_dels : backup_dir)
return keep_backup(fname);
return make_simple_backup(fname);
}
--
1.5.4.3.193.g6dd0e
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [PATCH] Add --no-y.
On Mon, Mar 10, 2008 at 10:55:26PM -0400, Matt McCutchen wrote: > When a bunch of --no-* options were added (852e763b), --no-y was > forgotten. Here it is. Thanks -- applied. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync itemizing "t" (should be "T") when lutimes fails on recreated symlink
On Mon, Mar 10, 2008 at 12:23:15AM -0400, Matt McCutchen wrote: > When rsync recreates a destination symlink to update its target path, > rsync will fail to preserve the time, but it nevertheless itemizes "t". This is now fixed in the git repository along with a couple other glitches that I turned up in the itemized output. As a part of all the fixing, I changed the itemized output of symlinks, devices, and special files to put a 'c' into the checksum/change field. This ensures that changes that are happening show up in the itemized output and are able to be differentiated from the copying of unchanged items when using the --copy-dest option. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[PATCH] Add --no-y.
---
When a bunch of --no-* options were added (852e763b), --no-y was
forgotten. Here it is.
Matt
options.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/options.c b/options.c
index 4ac8846..82597bf 100644
--- a/options.c
+++ b/options.c
@@ -577,6 +577,7 @@ static struct poptOption long_options[] = {
{"link-dest",0, POPT_ARG_STRING, 0, OPT_LINK_DEST, 0, 0 },
{"fuzzy", 'y', POPT_ARG_VAL,&fuzzy_basis, 1, 0, 0 },
{"no-fuzzy", 0, POPT_ARG_VAL,&fuzzy_basis, 0, 0, 0 },
+ {"no-y", 0, POPT_ARG_VAL,&fuzzy_basis, 0, 0, 0 },
{"compress",'z', POPT_ARG_NONE, 0, 'z', 0, 0 },
{"no-compress", 0, POPT_ARG_VAL,&do_compression, 0, 0, 0 },
{"no-z", 0, POPT_ARG_VAL,&do_compression, 0, 0, 0 },
--
1.5.4.3.193.g6dd0e
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Rsync 3.0.0 universal binary availible?
Hi All, So far the tests show the universal build of rsync 3.0 (using lipo) to be indeed universal. Metadata tests all come up clean on OSX Tiger and Leopard, both PPC and Intel architectures. Some people asked for the compiled binary so I put it here: http://rdutoit.home.comcast.net/~rdutoit/dir/lip.zip Thanks, Rob D -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Rsync maintainability
Wayne, Hopefully this will turn out to be unfounded like my concern about the hanging, but...I'm wondering whether anyone other than you understands the rsync source code well enough to maintain it in the event that, for some reason, you no longer did. After two years, I understand some parts of the code pretty well and can figure out most of the remainder when I need to. However, there are some regions, such as the I/O code and the incremental-recursion file-list code, where my understanding is shaky: while I might be able to read through them and mostly see what the code is doing, any change I made might break things in complex ways. I certainly don't feel that I could competently maintain those areas of rsync. I realize that your job is to produce an rsync that works, not necessarily one that I can understand. Quite possibly I am just out of my depth. Is there someone else listening who would be able to maintain rsync? Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: New rsync option checksum-path
On Mon, Mar 10, 2008 at 01:37:25PM -0300, Ruy Exel wrote: > Suspecting that the changes were made only to ID3 tags, a very common > situation, one could write a shell script, say SHORTSUM, which would > calculate a checksum only on the first 10K bytes, for example, where > ID3 tags reside. One thing you can do is to use the existing patch, checksum-reading, which allows the exchange of pre-computed checksum information that is matched against a more strict set of stat values than the normal "quick check" (i.e. it includes ctime and inode). You could modify the included perl script (support/rsyncsums) so that it generates a checksum using an alternate means than the normal full-file checksum (which is cached as an MD4 and an MD5 checksum for both old and new protocols -- so just change both values to the same alternate sum). As long as you regularly run the rsyncsums script on both systems (and make sure that both the sender and the receiver rsync get the --sumfiles=strict option), then rsync will figure out which files have really changed without having to read all the files. (Even the rsyncsums script run is efficient, as it just updates files where the mtime/ctime/size/inode have changed since the last cache.) Note that the above solution doesn't require that you alter the checksum method in order to make things fast, so you could just leave it alone if you are willing to make regular runs of the rsyncsums script. You do need to be careful not to use the rsyncsums script on files that are being actively written, as there is a small window where a race condition can bite you. To trigger it, rsync needs to stat a file with the same mtime and ctime as the current time, read the file, re-stat the file and discover that the stat info is unchanged (including no change in size), and also have a concurrent writer that changes the file's data during the period in between when rsync reads the file but before the end of the current second, with no further changes being made to the file after the current second ends. The rsyncsums script could be changed to not cache the checksum of a file which has a "now" ctime value, which would avoid this, but it does not do that at the moment. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: New rsync option checksum-path
On Mon, 2008-03-10 at 13:37 -0300, Ruy Exel wrote: > This is a suggestion for adding to rsync an option "--checksum-path=PROGRAM". > > Once this option is given, provided it is accompained by option > "--checksum", both the receiving and sending side of rsync would > compute checksums calling PROGRAM, instead of the usual checksum > program. I don't think this option would be useful to enough people to justify including it in the official rsync (of course, the final decision is Wayne's), but by all means make your own version of rsync with the option if it does what you need. Another approach would be to write a script that runs the custom checksum program on the source and destination files, determines which source files need to be copied, and passes the list to rsync with --files-from . Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: PGP keys?
On Mon, 2008-03-10 at 16:50 +0100, Anonymous wrote: > There is a PGP signature for R3 rsync but the PGP key is not found on > the website. How to obtain the pubkey? See: http://lists.samba.org/archive/rsync/2008-March/020257.html Wayne, please do put the information about the key on the Web site. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: crypting remote data
On Mon, 2008-03-10 at 22:55 +0100, david reinares wrote: > After testing a bit more i discovered that fails when i pass the > command to restore and decrypt with dest-filter (in the client side). > Always the same file, no matter how many times i execute rsync. But > after testing diferent folders, i can't see the conection between the > failed files. html, java, etc, but all of them with more files exactly > like them in the folder but rsync'd and decrypted perfectly. > If i do the same with source-filter (server side) it seems to work ok, > i can restore all files. But that is a problem, because we don't want > to have the files decrypted in the server not even for a second, > appart of the fact that having a big bunch of clients restoring at the > same time with all the hard work of decrypting in the server side > would overload the server. > > > -- > Very good this patch...thank you > > I've been testing this after patching rsync, and works fine to backup...but > > when I'm restoring the crypted data after a while rsync shows > rsync: Failed to close: Bad file descriptor (9) > rsync: Failed dup/close: Bad file descriptor (9) > rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0] > > rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0] > rsync: connection unexpectedly closed (55 bytes received so far) [generator] > rsync error: error in rsync protocol data stream (code 12) at io.c(600) > > [generat > or=3.0.0] > > It's a bit strange. It restores some files before failing, and they are > perfectly decrypted...i'm using openssl as command I will look into the problem with the patch if I get a chance. One workaround for restoring files would be to rsync the desired files to the target machine without filtering and then decrypt them there (with rsync and --source-filter or just a shell script). Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: crypting remote data
After testing a bit more i discovered that fails when i pass the command to restore and decrypt with dest-filter (in the client side). Always the same file, no matter how many times i execute rsync. But after testing diferent folders, i can't see the conection between the failed files. html, java, etc, but all of them with more files exactly like them in the folder but rsync'd and decrypted perfectly. If i do the same with source-filter (server side) it seems to work ok, i can restore all files. But that is a problem, because we don't want to have the files decrypted in the server not even for a second, appart of the fact that having a big bunch of clients restoring at the same time with all the hard work of decrypting in the server side would overload the server. -- Very good this patch...thank you I've been testing this after patching rsync, and works fine to backup...but when I'm restoring the crypted data after a while rsync shows rsync: Failed to close: Bad file descriptor (9) rsync: Failed dup/close: Bad file descriptor (9) rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0] rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0] rsync: connection unexpectedly closed (55 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generat or=3.0.0] It's a bit strange. It restores some files before failing, and they are perfectly decrypted...i'm using openssl as command --- On Sat, 2008-03-08 at 18:33 +0100, david reinares wrote: > rsyncrypto looks fine, but still not which we're looking for. > > Having a complete file updated if a little change happens doesn't > bother me. We're performing daily rsync, so not many files can be > changed in a day. > > The real problem is about space and performance. If you want good > performance yo have to sacrifice space, and vice versa. > > We decided to save space for client. so we copy file by file, crypt > it, rsync it, and then delete...a hell for performance, starting a > rsync connection for each file. > And worst of all, we loose -b functionality, that was really good > (having not just a copy of the day before but an extra day)...having a > previous version of destination data > in a file by file basis is not a god idea. I don't understand what problem you are having with -b; could you please clarify? Suffixed backups should work exactly the same way when rsyncing one file at a time as they did when you rsynced all the files at once. The same is true of backups with --backup-dir, provided that you use --relative so you can specify the same destination argument for every run. > Any idea to get the -b funcionality back again and obtain a compromise > between space and performance? To fix the performance while keeping the space usage low, look into the "source-filter_dest-filter" branch of rsync: http://rsync.samba.org/ftp/rsync/dev/patches/source-filter_dest-filter.diff You could run rsync once for all the files and specify your encryption program as the --source-filter, and rsync would call your encryption program once per file as needed. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
PGP keys?
There is a PGP signature for R3 rsync but the PGP key is not found on the website. How to obtain the pubkey? -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
New rsync option checksum-path
This is a suggestion for adding to rsync an option "--checksum-path=PROGRAM". Once this option is given, provided it is accompained by option "--checksum", both the receiving and sending side of rsync would compute checksums calling PROGRAM, instead of the usual checksum program. Why is this usefull? Suppose I have two collections of MP3 files at different locations which I want to upate. Suppose also that for some reason the testing of modtime is not efficient for distinguishing changeg files. Recall that changes to ID3 tags inside MP3 files do not change filesizes, and hence neither filesize is a good criteria for identifying changes. Suspecting that the changes were made only to ID3 tags, a very common situation, one could write a shell script, say SHORTSUM, which would calculate a checksum only on the first 10K bytes, for example, where ID3 tags reside. Using rsync -av --checksum-path=SHORSUM --checksum /LOCAL-MP3-DIRECTORY/ SERVER:/REMOTE-MP3-DIRECTORY/ would therefore save a lot of processing power. I am aware that rsync was designed in a way to dispense with previous knowledge of how files are structured. However, a simple change as proposed would allow users to custumize rsync based on such knowledge. Sincerely, Ruy Exel -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: The server is configured to refuse --iconv
On Mon, Mar 10, 2008 at 10:37:51AM +, Stuart Halliday wrote: > But I'm not using option --iconv! It looks like the cwRsync binary was created with a default --iconv option enabled (this is possible via a configure option). From the other messages I saw, it appears that the default is "--iconv=." (which is rsync's cryptic way of saying "use default charset on both sides"). As others have noted, setting a "charset = FOO" on the daemon side (in the rsyncd.conf) enables the allowing of clients that use --iconv. Or, you can manually turn off the default iconv-action for a single transfer via --no-iconv to the client rsync. You can also override a compiled-in default for all your commands by exporting the RSYNC_ICONV environment variable; e.g. set it to "-" to disable iconv by default. ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: crypting remote data
Very good this patch...thank you I've been testing this after patching rsync, and works fine to backup...but when I'm restoring the crypted data after a while rsync shows rsync: Failed to close: Bad file descriptor (9) rsync: Failed dup/close: Bad file descriptor (9) rsync error: error in IPC code (code 14) at pipe.c(208) [receiver=3.0.0] rsync error: error in IPC code (code 14) at pipe.c(195) [receiver=3.0.0] rsync: connection unexpectedly closed (55 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(600) [generat or=3.0.0] It's a bit strange. It restores some files before failing, and they are perfectly decrypted...i'm using openssl as command --- On Sat, 2008-03-08 at 18:33 +0100, david reinares wrote: > rsyncrypto looks fine, but still not which we're looking for. > > Having a complete file updated if a little change happens doesn't > bother me. We're performing daily rsync, so not many files can be > changed in a day. > > The real problem is about space and performance. If you want good > performance yo have to sacrifice space, and vice versa. > > We decided to save space for client. so we copy file by file, crypt > it, rsync it, and then delete...a hell for performance, starting a > rsync connection for each file. > And worst of all, we loose -b functionality, that was really good > (having not just a copy of the day before but an extra day)...having a > previous version of destination data > in a file by file basis is not a god idea. I don't understand what problem you are having with -b; could you please clarify? Suffixed backups should work exactly the same way when rsyncing one file at a time as they did when you rsynced all the files at once. The same is true of backups with --backup-dir, provided that you use --relative so you can specify the same destination argument for every run. > Any idea to get the -b funcionality back again and obtain a compromise > between space and performance? To fix the performance while keeping the space usage low, look into the "source-filter_dest-filter" branch of rsync: http://rsync.samba.org/ftp/rsync/dev/patches/source-filter_dest-filter.diff You could run rsync once for all the files and specify your encryption program as the --source-filter, and rsync would call your encryption program once per file as needed. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Deleting modified files
On Mon, 2008-03-10 at 10:04 +0100, Thomas Poindessous wrote: > Yes, I try to do the first solution, so I will have the possibility to > coordinate upgrade on several servers to reduce the differences. > > So, do I need to use a option of rsync to list modifications and then, > rm -f files ? Or is there a quickier and easier solution ? Just "rm" files (and "rmdir" empty directories) from base/etc that have counterparts in server/etc/ ; I can't come up with any better solution. I don't think you need to list modifications because, by virtue of your --compare-dest option, rsync will only copy files to server/etc/ that differ from their counterparts in base/etc/ . (Perhaps you were trying to handle the case where a file that previously differed among servers becomes the same, but it's not clear to me how that would have worked.) Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync: always modify atime of all destination files
On Thu, 2008-03-06 at 11:38 -0500, Justin Pryzby wrote: > On Fri, Jul 23, 2004 at 05:09:09PM -0300, Pedro Zorzenon Neto wrote: > > Please apply the following patch to rsync. This patch updates the > > atime (last access time) of all destination files to NOW when rsync > > runs. > > > > It is desirable to know if a file has been deleted in then source > > and exists in destination. Checking destination computer for atime, > > you can know how long this file has been removed from source, and > > remove it after some months to keep disk space in backups. I don't think this behavior would be useful to enough people to justify adding it to the official rsync, even as an option. Also, I think the atime, however convenient, is a poor way to store file expiration information because it can easily be modified accidentally by reading a file and it is not preserved if the backup itself is migrated with rsync. An alternative that is well-supported by rsync is to use --delete with a different --backup-dir for each run and delete backup dirs as they become 60 days old. Matt -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync: Please add an option to ignore vanished files
On Thu, 2008-03-06 at 11:56 -0500, Justin Pryzby wrote:
> On Mon, Feb 20, 2006 at 02:28:50PM +0300, Cyril Bouthors wrote:
> > I'd like rsync to provide an option called '--ignore-vanished' that
> > would not display those warnings anymore and not exit with value 24
> > ("Partial transfer due to vanished source files" according to the
> > manpage).
See:
https://bugzilla.samba.org/show_bug.cgi?id=3653
Andreas Kotes had exactly the same proposal, but I'm thinking that
instead of adding an option to suppress a warning that in one case can
indicate an incorrect transfer, it would be better to improve the design
of rsync so the warning can no longer happen.
Matt
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Deleting modified files
On Sat, Mar 8, 2008 at 4:10 AM, Matt McCutchen <[EMAIL PROTECTED]> wrote: > On Fri, 2008-03-07 at 22:21 +0100, Thomas Poindessous wrote: > > I'm trying to do a backup of several servers which are almost > > identical. I want to have a "base" directory and one directory by > > server. > > > > The base directory will have only the files which are identical on all > > the servers, and each server directory will have all of the other > > files which are not in base directory. > > Do you need to be able to look at the backup and see which files are > identical and different, or are you just trying to save space? In the > second case, it would be much easier to use a full directory for each > server and use --link-dest to hard-link identical corresponding files > among these directories. Yes, I try to do the first solution, so I will have the possibility to coordinate upgrade on several servers to reduce the differences. So, do I need to use a option of rsync to list modifications and then, rm -f files ? Or is there a quickier and easier solution ? > > I also have a problem with --compare-dest and --checksum because > > sometimes files are identical on each server but they have different > > modification time. > > Please be more specific about what the problem is. Do you consider > modification times to be significant? If so, use -t; rsync will > preserve the times, and they will disqualify --compare-dest omissions > and --link-dest links. If not, use --checksum and do not use -t, and > rsync won't deal with times at all. (Rsync does not provide a way to > get the preservation without the disqualification, unless you want to > use multiple runs.) Thanks a lot for this clarification, I now use --compare-dest with --checksum and --no-t and it works great. Thomas -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: The server is configured to refuse --iconv
Thank you Tevfik, I added "charset = utf-8" to the rsync server's .conf and it now works. I didn't realise that Rsync 3 now converts filenames between machines now? -- Stuart Halliday -Original Message- From: Tevfik Karagülle <[EMAIL PROTECTED]> To: "'Stuart Halliday'" <[EMAIL PROTECTED]>, Date: Mon, 10 Mar 2008 12:05:41 +0100 Subject: RE: The server is configured to refuse --iconv > See a related thread in cwrsync forum > > http://www.itefix.no/phpws/index.php?module=phpwsbb&PHPWSBB_MAN_OP=view > &PHPW > S_MAN_ITEMS[]=1130 > > > Tev > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Stuart Halliday > > Sent: 10. mars 2008 11:38 > > To: rsync@lists.samba.org > > Subject: The server is configured to refuse --iconv > > > > I've just tried upgrading to cwrsync 2.1.0 (Rsync version > > 3.0.0 protocol version 30) between 2 Windows XP Pro sp2 > > machine across the Internet. > > > > I used: > > SET CYGWIN=nontsec > > SET HOME=c:\cwrsync\bin > > C:\cwrsync\bin\rsync -za -u -P --delete --recursive > > /cygdrive/c/test2/ [EMAIL PROTECTED]::test/ > > > > When I run the above batch script on the remote machine I get > > this odd output. > > > > -- > > -- > > sending incremental file list > > rsync: The server is configured to refuse --iconv rsync > > error: requested action not supported (code 4) at > > clientserver.c(810) [receiver=3.0.0] > > rsync: connection unexpectedly closed (5 bytes received so > > far) [sender] rsync error: error in rsync protocol data > > stream (code 12) at io.c(609) [sender=3.0.0] Press any key to > > continue . . . > > -- > > -- > > But I'm not using option --iconv! > > > > Where does it say it refuses --iconv? > > > > I admit I'm a bit lost. :-) > > > > > > > > Server side rsync is started via > > --config rsyncd.conf --daemon --no-detach as a service. > > Registry settings are: > > -- > > -- > > Windows Registry Editor Version 5.00 > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer] > > "Type"=dword:0010 > > "Start"=dword:0002 > > "ErrorControl"=dword:0001 > > "ImagePath"=hex(2):43,00,3a,00,5c,00,63,00,77,00,52,00,73,00,7 > > 9,00,6e,00,63,00,\ > > > > 5c,00,62,00,69,00,6e,00,5c,00,63,00,79,00,67,00,72,00,75,00,6e > > ,00,73,00,72,\ > > 00,76,00,2e,00,65,00,78,00,65,00,00,00 > > "DisplayName"="RsyncServer" > > "ObjectName"=".\\stuart" > > "Description"="Rsync - open source utility that provides fast > > incremental file transfer" > > "FailureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,03,00 > > ,00,00,50,00,70,\ > > > > 00,01,00,00,00,20,bf,02,00,01,00,00,00,20,bf,02,00,01,00,00,00 > > ,20,bf,02,00 > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > > ver\Parameters] > > "AppPath"="C:\\cwRsync\\bin\\rsync.exe" > > "AppArgs"="--config rsyncd.conf --daemon --no-detach" > > "WorkingDirectory"="C:\\cwRsync" > > "StdOut"="C:\\cwRsync\\rsyncd-stdin.log" > > "StdErr"="C:\\cwRsync\\rsyncd-stderr.log" > > "Shutdown"=dword:0001 > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > > ver\Parameters\Environment] > > "CYGWIN"="nontsec binmode" > > > > > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > > ver\Enum] > > "0"="Root\\LEGACY_RSYNCSERVER\\" > > "Count"=dword:0001 > > "NextInstance"=dword:0001 > > > > rsyncd.conf is: > > -- > > - > > log file = rsyncd.log > > pid file = rsyncd.pid > > use chroot=false > > uid=administrator > > gid=administrators > > strict modes = false > > [test] > > path=/cygdrive/ctest > > comment=Nothing to see here. Empty. > > read only=false > > transfer logging = yes > > list=yes > > auth users=stuart > > > > > > Even just attempting to list the contents of this remote > > directory gives this error. > > The directory contains one file called 'test_text_file.txt' > > > > > > -- > > Stuart Halliday > > > > > > > > This email is the property of ECS Technology Ltd. > > This company is registered in Scotland with company number 212513. > > VAT registered GB 761 7456 12 > > http://www.ecs-tech.com/ > > > > > > -- > > To unsubscribe or change options: > > https://lists.samba.org/mailman/listinfo/rsync > > Before posting, read: > > http://www.catb.org/~esr/faqs/smart-questions.html > > > > -- > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: > http://www.catb.org/~esr/faqs/smart-questions.html This email is the property of ECS Technology Ltd. This company is regi
DO NOT REPLY [Bug 5309] double free or corruption while using rsync 3.0.0 stable
https://bugzilla.samba.org/show_bug.cgi?id=5309 --- Comment #2 from [EMAIL PROTECTED] 2008-03-10 06:13 CST --- strange: if I compile rsync with "enable maintainer mode" and run the rsync -client as root from bash, after the crash it tells me "xterm ...: Can´t open display" for some more debug output. Why do I need a XTerm for the output? if I run the client as non root, it tells me that -A is an unknown option Anyway, this is how you can reproduce the crash (hopefully): At the source server at an xfs-partition create a folder with a default acl. The folder should contain some files. At the destination server sync this folder with my options (rsync -pAzbrv). Make sure the folder with ACLs does not exist in the trash. To be sure rsync tries to create the folder in the trash directory, don´t use -u. You should notice that rsync creates the folder with ACLs in the trash dir, but not the files in the folder. At that moment the crash happens. regards Sigi -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: The server is configured to refuse --iconv
See a related thread in cwrsync forum http://www.itefix.no/phpws/index.php?module=phpwsbb&PHPWSBB_MAN_OP=view&PHPW S_MAN_ITEMS[]=1130 Tev > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Stuart Halliday > Sent: 10. mars 2008 11:38 > To: rsync@lists.samba.org > Subject: The server is configured to refuse --iconv > > I've just tried upgrading to cwrsync 2.1.0 (Rsync version > 3.0.0 protocol version 30) between 2 Windows XP Pro sp2 > machine across the Internet. > > I used: > SET CYGWIN=nontsec > SET HOME=c:\cwrsync\bin > C:\cwrsync\bin\rsync -za -u -P --delete --recursive > /cygdrive/c/test2/ [EMAIL PROTECTED]::test/ > > When I run the above batch script on the remote machine I get > this odd output. > > -- > -- > sending incremental file list > rsync: The server is configured to refuse --iconv rsync > error: requested action not supported (code 4) at > clientserver.c(810) [receiver=3.0.0] > rsync: connection unexpectedly closed (5 bytes received so > far) [sender] rsync error: error in rsync protocol data > stream (code 12) at io.c(609) [sender=3.0.0] Press any key to > continue . . . > -- > -- > But I'm not using option --iconv! > > Where does it say it refuses --iconv? > > I admit I'm a bit lost. :-) > > > > Server side rsync is started via > --config rsyncd.conf --daemon --no-detach as a service. > Registry settings are: > -- > -- > Windows Registry Editor Version 5.00 > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer] > "Type"=dword:0010 > "Start"=dword:0002 > "ErrorControl"=dword:0001 > "ImagePath"=hex(2):43,00,3a,00,5c,00,63,00,77,00,52,00,73,00,7 > 9,00,6e,00,63,00,\ > > 5c,00,62,00,69,00,6e,00,5c,00,63,00,79,00,67,00,72,00,75,00,6e > ,00,73,00,72,\ > 00,76,00,2e,00,65,00,78,00,65,00,00,00 > "DisplayName"="RsyncServer" > "ObjectName"=".\\stuart" > "Description"="Rsync - open source utility that provides fast > incremental file transfer" > "FailureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,03,00 > ,00,00,50,00,70,\ > > 00,01,00,00,00,20,bf,02,00,01,00,00,00,20,bf,02,00,01,00,00,00 > ,20,bf,02,00 > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > ver\Parameters] > "AppPath"="C:\\cwRsync\\bin\\rsync.exe" > "AppArgs"="--config rsyncd.conf --daemon --no-detach" > "WorkingDirectory"="C:\\cwRsync" > "StdOut"="C:\\cwRsync\\rsyncd-stdin.log" > "StdErr"="C:\\cwRsync\\rsyncd-stderr.log" > "Shutdown"=dword:0001 > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > ver\Parameters\Environment] > "CYGWIN"="nontsec binmode" > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncSer > ver\Enum] > "0"="Root\\LEGACY_RSYNCSERVER\\" > "Count"=dword:0001 > "NextInstance"=dword:0001 > > rsyncd.conf is: > -- > - > log file = rsyncd.log > pid file = rsyncd.pid > use chroot=false > uid=administrator > gid=administrators > strict modes = false > [test] > path=/cygdrive/ctest > comment=Nothing to see here. Empty. > read only=false > transfer logging = yes > list=yes > auth users=stuart > > > Even just attempting to list the contents of this remote > directory gives this error. > The directory contains one file called 'test_text_file.txt' > > > -- > Stuart Halliday > > > > This email is the property of ECS Technology Ltd. > This company is registered in Scotland with company number 212513. > VAT registered GB 761 7456 12 > http://www.ecs-tech.com/ > > > -- > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: > http://www.catb.org/~esr/faqs/smart-questions.html > -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
The server is configured to refuse --iconv
I've just tried upgrading to cwrsync 2.1.0 (Rsync version 3.0.0 protocol version 30) between 2 Windows XP Pro sp2 machine across the Internet. I used: SET CYGWIN=nontsec SET HOME=c:\cwrsync\bin C:\cwrsync\bin\rsync -za -u -P --delete --recursive /cygdrive/c/test2/ [EMAIL PROTECTED]::test/ When I run the above batch script on the remote machine I get this odd output. sending incremental file list rsync: The server is configured to refuse --iconv rsync error: requested action not supported (code 4) at clientserver.c(810) [receiver=3.0.0] rsync: connection unexpectedly closed (5 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(609) [sender=3.0.0] Press any key to continue . . . But I'm not using option --iconv! Where does it say it refuses --iconv? I admit I'm a bit lost. :-) Server side rsync is started via --config rsyncd.conf --daemon --no-detach as a service. Registry settings are: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer] "Type"=dword:0010 "Start"=dword:0002 "ErrorControl"=dword:0001 "ImagePath"=hex(2):43,00,3a,00,5c,00,63,00,77,00,52,00,73,00,79,00,6e,00,63,00,\ 5c,00,62,00,69,00,6e,00,5c,00,63,00,79,00,67,00,72,00,75,00,6e,00,73,00,72,\ 00,76,00,2e,00,65,00,78,00,65,00,00,00 "DisplayName"="RsyncServer" "ObjectName"=".\\stuart" "Description"="Rsync - open source utility that provides fast incremental file transfer" "FailureActions"=hex:00,00,00,00,00,00,00,00,00,00,00,00,03,00,00,00,50,00,70,\ 00,01,00,00,00,20,bf,02,00,01,00,00,00,20,bf,02,00,01,00,00,00,20,bf,02,00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer\Parameters] "AppPath"="C:\\cwRsync\\bin\\rsync.exe" "AppArgs"="--config rsyncd.conf --daemon --no-detach" "WorkingDirectory"="C:\\cwRsync" "StdOut"="C:\\cwRsync\\rsyncd-stdin.log" "StdErr"="C:\\cwRsync\\rsyncd-stderr.log" "Shutdown"=dword:0001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer\Parameters\Environment] "CYGWIN"="nontsec binmode" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RsyncServer\Enum] "0"="Root\\LEGACY_RSYNCSERVER\\" "Count"=dword:0001 "NextInstance"=dword:0001 rsyncd.conf is: --- log file = rsyncd.log pid file = rsyncd.pid use chroot=false uid=administrator gid=administrators strict modes = false [test] path=/cygdrive/ctest comment=Nothing to see here. Empty. read only=false transfer logging = yes list=yes auth users=stuart Even just attempting to list the contents of this remote directory gives this error. The directory contains one file called 'test_text_file.txt' -- Stuart Halliday This email is the property of ECS Technology Ltd. This company is registered in Scotland with company number 212513. VAT registered GB 761 7456 12 http://www.ecs-tech.com/ -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 3845] Make --remove-source-files remove directories too
https://bugzilla.samba.org/show_bug.cgi?id=3845 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #5 from [EMAIL PROTECTED] 2008-03-10 04:45 CST --- What's the status of this feature? The directory deletion feature is still missing. I'm on 2.6.9 but I couldn't find changes in the Changelog of 3.0. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync: Please add an option to ignore vanished files
Having not yet seen a response to this, here's my $.02...
On Thu, 6 Mar 2008, Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Hi Everyone,
>
> The following request was received from a Debian user; could you
> comment on it? I think this seems reasonable, although the cron
> output can be fixed by writing to a temporary file and using grep -v.
> (The temporary file is necessary to avoid discarding the exit code,
> although that may not be needed in the case of rsync, since it writes
> that to stderr).
>
> On Mon, Feb 20, 2006 at 02:28:50PM +0300, Cyril Bouthors wrote:
>> Package: rsync
>> Version: 2.6.6-1
>> Severity: wishlist
>>
>> I make nightly backups of 1TB+ of data that are continuously
>> read-write accessed and I constantly have *huge* output of the cron
>> job because of vanished files:
>>
>> file has vanished: "/drbd/var/www/tmp/sess_003323885e425f2a67e69e0ac4c24124"
>> (...)
>> [skipped tens of thousands of lines]
>>
>> I'd like rsync to provide an option called '--ignore-vanished' that
>> would not display those warnings anymore and not exit with value 24
>> ("Partial transfer due to vanished source files" according to the
>> manpage).
Instead of attacking the symptom, attack the problem. You are backing
up temporary files that are not needed on a restore. These "vanished"
messages actually help pinpoint directories whose contents should be
excluded, in this case via --exclude=/drbd/var/www/tmp/*
Also, if you want, you can also check the exit code within a script and
treat value 24 the same as a 0 (e.g. no extra warnings about failure).
John Van Essen
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
