x EA Techsupport has moved.
i really need help with my computer. my computer says a file is missing from my computer and i don't know what to do after that. can you help me? sincerely, val d. Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses.-- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 1673] Verbose dry run doesn't report replacements of symlink with directory
https://bugzilla.samba.org/show_bug.cgi?id=1673 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 14:37 --- This is now fixed in the CVS version. It became very easy to fix after some recent changes I made provided the hierarchical depth value for each file, which means that anytime a directory is missing in --dry-run mode, we just need to ignore all items that are deeper in the list up to the next item that is less-than or equal-to the missing depth. Note that there is a potential for the incorrect output to occur when talking to an older rsync (prior to protocol 29). This is because the sort algorithm in earlier rsyncs might put an item from outside a directory's hierarchy in between the directory and its contents. To see this in action, update to the CVS version (also available in the latest nightly tar file), add a file named projects.txt in the a dir of the above test-case, and verify that the --dry-run output works properly. Then, repeat the test with the debug option --protocol=28 and the items inside the projects dir will not be listed in --dry-run mode (because projects.txt sorted in between the dir and its contents). -- 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
[Bug 2296] Idea: transparently uncompress .gz and .bz2 files before synchronizing.
https://bugzilla.samba.org/show_bug.cgi?id=2296 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P5 Version|2.6.3 |2.6.4 --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 14:44 --- I'm not that enamored with this idea, but I'll leave this open as a place-holder for future consideration. -- 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
[Bug 2294] Detect renamed files and handle by renaming instead of delete/re-send
https://bugzilla.samba.org/show_bug.cgi?id=2294 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 14:49 --- This is the basic idea behind fuzzy.diff in the patches dir. It does not currently try to find a basis-file match based on size and mtime (just similarity of names), but I plan to extend it with that functionality when I fix some of the patch's other minor problems (see the patch for a list of them). -- 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
[Bug 1889] Keep Alive packets
https://bugzilla.samba.org/show_bug.cgi?id=1889 --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 15:05 --- Note that in the new version, this too-long receiver-side scan can be avoided by using --delete-during (--del). However, I'm still considering adding a keep alive message. -- 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
[Bug 2104] Add support for --dry-run with --write-batch
https://bugzilla.samba.org/show_bug.cgi?id=2104 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 15:01 --- This should not be that hard. The generator would need to be modified so that it actually computes the checksums and sends them to the sender in this mode and (for a push) the sender would need to be enhanced to output its changes to the batch fd instead of the socket, or (for a pull) the sender would need to go ahead and send its update data down the socket while the receiver would just throw away the update data after recording it. Also, the --write-batch option would need to be sent to a server sender (which it is not currently) to trigger the right mode (when pulling files). Care needs to be taken to test for compatibilty problems in this regard (since we currently avoid sending --write-batch to the server for compatibility reasons). -- 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
[Bug 2256] failes to compress
https://bugzilla.samba.org/show_bug.cgi?id=2256 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-12 15:13 --- I think you probably mean that the destination files weren't compressed, which is not what this option does. I just checked the man page, and it is not clear at all what data the -z option is affecting (which is just the over-the-wire data), so I'll fix that. If I'm wrong about what you meant to report, feel free to reopen the bug. -- 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
Rsync friendly zlib/gzip compression - revisited
Hi, all - I've been digging into the question of using rsync to sync up compressed data, and read with interest the conversations regarding the rsync friendly patch available for gzip (I belive Rusty provided this patch). For anyone interested, the message thread is archived at http://lists.samba.org/archive/rsync/2002-June/thread.html. The broad outline of this approach were mentioned in Andrew Tridgell's PhD thesis, and explained in more depth in a transcript of a talk he gave. My initial thought on reading this was no way this will work - then I dug in, and convinced myself that it would indeed work. After testing Rusty's patch, I am extremely convinced that the approach works - very elegent. At that point, I started to consider the question raised in the discussion threads by Kevin Easton - primarily: are the checksum and compression block trigger selected by Rusty optimal? To refresh memories: Rusty's checksum algorithm is to compute the sum of the previous 4096 bytes of source data, and his block trigger kicks in when the checksum is divisible by 4096 (i.e. SUM mod 4096 == 0). Because the value of 4096 prior bytes seemed fairly arbitrary, and because modding by the same value as the window size seemed somewhat arbitrary, I decided to do some parametric tests with a couple of different checksum strategies, window sizes and block trigger mask sizes. The following is pretty long - I apologize for making my first post on the topic so extensive - but the results are interesting, and I figured I'd lay out everything that I have so far to see if anyone a) is interested or b) has any ideas of directions to pursue... Test Description == Here are some definitions: SUM = the value of the rolling checksum at a given point in the input stream Window size = the number of bytes in the input stream that are considered for the rolling check sum Block mask size = The size of value used in checking the current SUM to see if the current compression block should be wrapped up Compression block size = The number of bytes from the input stream between checksum triggers I decided to test using two forms of rolling checksum: 1. Rusty's strategy of just adding the values from the input stream 2. Andrew's rolling checksum that is used in the rsync algorithm itself For starters (I'm still working on processing tests on a larger data set), I chose a 28 MB database file (dBase file) - fixed record size, lot's of compression opportunities. I then constructed a parametric study to see the impact of window size, block mask size and algorithm based on the database file as an input file. The output of the tests is the average compression block size, and the standard deviation of the compression block size. For the initial tests here (more follow!), this is run in a test harness that just computes effective block sizes based on the two checksum algorithms - it is NOT running the patched zlib/gzip code directly (I do that testing later on). The results should help us understand the dependencies between different parameters, which will help determine how to pursue future testing. My thinking here is as follows: Average compressed block size The average compression block size is going to pretty much dictate the overall effectiveness of the zlib/gzip underlying compression algorithm. Ideally, we want to have a control that we can tune to adjust this value so we get decent performance from zlib, but not have blocks that are too big (which would reduce the effectiveness of the rsync operation itself). The zlib algorithm's performance is non-linear with respect to the compression block size, so finding this balance point is particularly important from an optimization perspective. In general, I find that block sizes around 4000 - 5000 seem to be about optimal - anything below that, and the compression drops off. Anything above, and the compression doesn't improve much. Std deviation of compressed block size I initially thought that the standard deviation of the compression block size would be important because of the non-linear behavior of the zlib compression algorithm with respect to block size. If our standard deviation is too high, then we might have a great average block size, but most blocks will be significantly above or below the average, so the effective performance of both the compression and rsync pieces of the problem will be far from optimal. Another way of putting this: If I say that there isn't a good deal of improvement in compression ratio for compression block sizes above 4000 bytes, then I would optimally choose my checksum algorithm and parameters so that 4000 = (Xavg - Xsigma). If I have a small Xsigma, that allows me to have a smaller Xavg. And smaller Xavg *should* translate into better rsync performance. I have NOT tested this yet, but it is
macro feature tests in rsync code
The tests in rsync for features have been changed to testing the value of a macro definition instead of previously testing if the macro was defined. This testing is now inconsistent with the HAVE_SOCKETPAIR macro, where in some places it is tested to see if the macro is defined, and other places to if it has a non zero value. I would rather not globally disable the diagnostic about undefined macros, as it has shown in the past to help find programming problems. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
#include inttypes.h missing for 64 bit integers.
The Open Group Single Unix standard shows that the data types int64 and uint64 are defined in the inttypes.h header file. Rsync is not including this file, nor is there a feature test for this header file in the configure phase, but rsync is using these data types. -John [EMAIL PROTECTED] Personal Opinion Only -- 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: #include inttypes.h missing for 64 bit integers.
John E. Malmberg wrote: The Open Group Single Unix standard shows that the data types int64 and uint64 are defined in the inttypes.h header file. Rsync is not including this file, nor is there a feature test for this header file in the configure phase, but rsync is using these data types. My error, the types on my system are in the ints.h header file, which I do not find in The Open Group's specifications. -John [EMAIL PROTECTED] Personal Opinion Only -- 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: macro feature tests in rsync code
On Sat, Feb 12, 2005 at 09:53:28PM -0500, John E. Malmberg wrote: The tests in rsync for features have been changed to testing the value of a macro definition instead of previously testing if the macro was defined. Acutally, the various tests were sometimes inconsistent -- some were testing if a config item was defined, and some testing if it was non-zero. I made them all consistent in their checking for a non-zero value. This testing is now inconsistent with the HAVE_SOCKETPAIR macro, where in some places it is tested to see if the macro is defined, and other places to if it has a non zero value. I don't see this. All the code in CVS uses #if to test the value of HAVE_SOCKETPAIR. I would rather not globally disable the diagnostic about undefined macros, as it has shown in the past to help find programming problems. I assume you're talking about gcc's -Wundef option. We could add -Wno-undef to the gcc CFLAGS setting in configure.in, like this: # If GCC, turn on warnings. if test x$GCC = xyes then CFLAGS=$CFLAGS -Wall -W -Wno-undef fi That would add the flag to the Makefile and should silence any warnings about this. ..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 to upload certain files and ignore others
On Thu, Feb 10, 2005 at 09:40:20AM -0800, jediknight2 wrote: Is there a way for RSYNC when its backing up a folder say c:\output to ignore certain file extentions as a whole...so basically ignore all other files EXCEPT *.gpg files? You can exclude all files except *.gpg files from the transfer (using --include='*.gpg' --exclude='*'), but there is no way to limit what files get backed up -- all updated files are backed up when --backup is specified. ..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
CVS update: rsync
Date: Sat Feb 12 18:40:16 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv26149 Modified Files: flist.c Log Message: - Since send_file_list() is no longer called with f == -1, got rid of all the conditional code to support that. - Improved the comment before send_directory() to indicate that it gets called with f == -1 from delete_in_dir(). Revisions: flist.c 1.266 = 1.267 http://www.samba.org/cgi-bin/cvsweb/rsync/flist.c?r1=1.266r2=1.267 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sat Feb 12 19:25:54 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv5486 Modified Files: sender-receiver-excludes.diff Log Message: - We don't need to ignore local rules in send_file_name() anymore when --delete-excluded was specified because the local filter list has already been pruned of any rules that don't apply on the receiver. This simplification removes the need for the code that set delete_excluded to 2 for protocol_version = 29. - Improved the code in get_rule_prefix() to always supply the full list of prefixes for protocol_version = 29. - Don't ever avoid a get_rule_prefix() when trimming the filter list without sending it because it is the function that tells us if a rule is too modern for the other side to deal with (e.g. if we couldn't send the protect rules to the receiver). Revisions: sender-receiver-excludes.diff 1.7 = 1.8 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/sender-receiver-excludes.diff?r1=1.7r2=1.8 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sat Feb 12 19:27:58 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv7632 Modified Files: fname-convert.diff Log Message: Fixed a failing hunk. Revisions: fname-convert.diff 1.27 = 1.28 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/fname-convert.diff?r1=1.27r2=1.28 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 19:52:18 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv14070 Modified Files: flist.c Log Message: We don't need to avoid the local filter list in send_file_name() when --delete-excluded is set because our list has been trimmed to only include rules that apply in the current mode. Revisions: flist.c 1.267 = 1.268 http://www.samba.org/cgi-bin/cvsweb/rsync/flist.c?r1=1.267r2=1.268 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 19:52:26 2005
Author: wayned
Update of /data/cvs/rsync
In directory dp.samba.org:/tmp/cvs-serv14103
Modified Files:
exclude.c
Log Message:
- Added modifiers for the include/exclude rules that makes them
apply to the indicated (sender/receiver) side.
- Added the hide/show and protect/risk filter rules as an alternate
way to specify sender-/receiver-specific include/exclude rules.
- send_rules() now allows f_out to be -1 to indicate that the list
should be scanned but not sent.
- send_rules() now filters the list to remove any items that don't
apply to the current side (after sending the item to the other
side when f_out != -1).
- {send,recv}_filter_list() now transfer the list, even when the
receiver is the server and --delete-excluded was specified (the
exchanged list is appropriately filtered, of course).
- recv_filter_list() uses send_rules() to trim non-applicable rules
when we're a local-server (because we got our filter list without
send/recv calls when fork() duplicated it).
Revisions:
exclude.c 1.109 = 1.110
http://www.samba.org/cgi-bin/cvsweb/rsync/exclude.c?r1=1.109r2=1.110
___
rsync-cvs mailing list
rsync-cvs@lists.samba.org
https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 19:52:35 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv14119 Modified Files: rsync.yo rsync.1 Log Message: Document the new filter rule flags for sender-/receiver-specific rules. Revisions: rsync.yo1.234 = 1.235 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.234r2=1.235 rsync.1 1.247 = 1.248 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.247r2=1.248 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 19:52:40 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv14143 Modified Files: NEWS Log Message: Mention the protocol change for --delete-excluded. Revisions: NEWS1.242 = 1.243 http://www.samba.org/cgi-bin/cvsweb/rsync/NEWS?r1=1.242r2=1.243 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sat Feb 12 19:54:17 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv14426 Removed Files: sender-receiver-excludes.diff Log Message: Applied to the trunk. Revisions: sender-receiver-excludes.diff 1.8 = NONE http://www.samba.org/cgi-bin/cvsweb/rsync/patches/sender-receiver-excludes.diff?rev=1.8 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sat Feb 12 20:01:28 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv16393 Modified Files: verify-patches Log Message: - Ignore 1-line of fuzz unless --minor-updates was specified. - Added --failures-only (-f) option. Revisions: verify-patches 1.18 = 1.19 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/verify-patches?r1=1.18r2=1.19 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sat Feb 12 20:01:43 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv16828 Modified Files: acls.diff Log Message: Fixed some patch fuzz. Revisions: acls.diff 1.28 = 1.29 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/acls.diff?r1=1.28r2=1.29 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/testsuite
Date: Sat Feb 12 20:25:12 2005 Author: wayned Update of /data/cvs/rsync/testsuite In directory dp.samba.org:/tmp/cvs-serv23356 Modified Files: rsync.fns Log Message: Improved checkit() and rsync_ls_lR() to work with filenames that might have spaces. Revisions: rsync.fns 1.63 = 1.64 http://www.samba.org/cgi-bin/cvsweb/rsync/testsuite/rsync.fns?r1=1.63r2=1.64 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/testsuite
Date: Sat Feb 12 20:45:39 2005 Author: wayned Update of /data/cvs/rsync/testsuite In directory dp.samba.org:/tmp/cvs-serv27824 Modified Files: exclude.test Log Message: Some more improvements to exercise rule-restricted merge files (i.e. exclude patterns only) and side-restricted filter rules. Revisions: exclude.test1.12 = 1.13 http://www.samba.org/cgi-bin/cvsweb/rsync/testsuite/exclude.test?r1=1.12r2=1.13 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 21:18:58 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv4948 Modified Files: generator.c Log Message: When --dry-run is set, note when a directory is missing and avoid trying to stat() any items inside that dir's hierarchy. This fixes a bug where a symlink to a dir getting replaced by a dir with identical contents to the dir at the other end of the symlink would not report the updated files in the new hierarchy. (See bug #1673) Revisions: generator.c 1.135 = 1.136 http://www.samba.org/cgi-bin/cvsweb/rsync/generator.c?r1=1.135r2=1.136 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/testsuite
Date: Sat Feb 12 21:22:21 2005 Author: wayned Update of /data/cvs/rsync/testsuite In directory dp.samba.org:/tmp/cvs-serv6197/testsuite Modified Files: exclude.test Log Message: Forgot to make sure that the dir-times on the chkdir got synced in the newest test case. Revisions: exclude.test1.13 = 1.14 http://www.samba.org/cgi-bin/cvsweb/rsync/testsuite/exclude.test?r1=1.13r2=1.14 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 22:21:45 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv21927 Modified Files: rsync.yo rsync.1 Log Message: Improved the documentation of the --compress (-z) option. Revisions: rsync.yo1.235 = 1.236 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.235r2=1.236 rsync.1 1.248 = 1.249 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.248r2=1.249 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sat Feb 12 22:22:14 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv22134 Modified Files: options.c Log Message: Improved the description of the --compress (-z) option. Revisions: options.c 1.228 = 1.229 http://www.samba.org/cgi-bin/cvsweb/rsync/options.c?r1=1.228r2=1.229 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Feb 13 05:44:29 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv10174 Modified Files: options.c Log Message: Improved the help text for -F. Revisions: options.c 1.229 = 1.230 http://www.samba.org/cgi-bin/cvsweb/rsync/options.c?r1=1.229r2=1.230 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Feb 13 05:45:43 2005 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv10694 Modified Files: rsync.yo rsync.1 Log Message: Improved the summary for the -F option. Revisions: rsync.yo1.236 = 1.237 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.236r2=1.237 rsync.1 1.249 = 1.250 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.249r2=1.250 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync/patches
Date: Sun Feb 13 07:00:01 2005 Author: wayned Update of /data/cvs/rsync/patches In directory dp.samba.org:/tmp/cvs-serv31975 Modified Files: copy-atimes.diff fname-convert.diff fuzzy.diff link-by-hash.diff Log Message: Fixed failing hunks. Revisions: copy-atimes.diff1.31 = 1.32 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/copy-atimes.diff?r1=1.31r2=1.32 fname-convert.diff 1.28 = 1.29 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/fname-convert.diff?r1=1.28r2=1.29 fuzzy.diff 1.54 = 1.55 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/fuzzy.diff?r1=1.54r2=1.55 link-by-hash.diff 1.36 = 1.37 http://www.samba.org/cgi-bin/cvsweb/rsync/patches/link-by-hash.diff?r1=1.36r2=1.37 ___ rsync-cvs mailing list rsync-cvs@lists.samba.org https://lists.samba.org/mailman/listinfo/rsync-cvs
