On Tue, May 27, 2008 at 10:43:00AM -0700, Stuart Anderson wrote:
> Nuts. I was afraid that was going to be the answer. Unfortunately,
> it violates the very helpful advise given above, i.e., run with "-v"
> and add exclude rules for files you don't want to transfer based
> on the output seen.
That
On Sat, May 24, 2008 at 02:44:33PM +0200, Gerben Wierda wrote:
> This looks like a bug to me.
Nope. Use "man rsyncd.conf" or read the manpage on-line (it's linked on
the front page of the rsync website):
http://rsync.samba.org/ftp/rsync/rsyncd.conf.html
This change was also announced in a s
On Fri, May 23, 2008 at 11:23:24AM -0500, Michael Short wrote:
> Would it be possible to analyze and store hashing information about
> file A before it is neccessary to compare it with file B? I want to
> know because in my software file A will not be available to either
> system when the new versi
On Thu, May 22, 2008 at 02:57:56PM -0500, Jordan Russell wrote:
> Under 3.0.x, rsync sometimes prints an "Invalid argument" error when
> moving sockets to the backup directory (--backup-dir):
Thanks for pointing this out. I have checked in a fix for this into the
git repository. You can see the
On Wed, May 21, 2008 at 11:30:39AM +0100, Joao Ferreira gmail wrote:
> can rsync sync some directory directlly into a compressed file format..
This is not currently supported. There's a patch that could allow such
a situation, but I don't recommend it. For backups, the BackupPC
software (listed
I have made rsync 3.0.3pre2 available for release testing. This is another
bug-fix release, with the only "enhancements" being made to the manpages and
the testsuite.
These are the changes that have happened since 3.0.3pre1:
- Fixed the combination of --xattrs and --backup.
- Fixed several pl
On Thu, May 15, 2008 at 03:47:51PM -0700, shmerl wrote:
> I.e. I use it like this: rsync --delay-updates --remove-source-files $1 $2
>
> My question is, what happenes first - does the file appear in destination
> (i.e. mv from ~tmp~ to dest), and then removed at the source host, or it is
> first r
On Fri, May 16, 2008 at 12:07:47PM -0500, Jordan Russell wrote:
> rsync: make_bak_dir mkdir "/backup/server/../server-before-5/var" failed:
> File exists (17)
> rsync: keep_backup failed: "/backup/server/var/lib/rpcbind/rpcbind.file" ->
> "../server-before-5/var/lib/rpcbind/rpcbind.file": Success
On Thu, May 15, 2008 at 06:39:03PM -0400, Matt McCutchen wrote:
> Wayne, do you have a comment about the inclusion of --ignore-case?
I don't particularly like the option, so my current inclination is to
just keep it available in the patches directory for those that want it.
..wayne..
--
Please u
On Wed, May 14, 2008 at 03:55:40PM -0400, Victor Farah wrote:
> I need to know if it can save the file list it generates and
> uses it over again for the other machines?
As long as each of the machines you are updating is in the same state,
you can use a batch file to update them all. Create the
On Tue, May 06, 2008 at 06:27:27PM -0700, Patrick Nolan wrote:
> I thought the -q option and the redirection to /dev/null would
> keep it quiet under normal circumstances. Apparently not.
It should. You shouldn't even require -q since you're not using -v.
I tried out your setup, and didn't get a
On Thu, May 08, 2008 at 08:59:41AM -0700, arguellodw wrote:
> rsync error: timeout in data send/receive (code 30) at
> /home/lapo/packaging/tmp/rsync-2.6.3/io.c(153)
You are reaching your idle-time timeout. Either make it larger (e.g.
--timeout=360) or upgrade to a newer rsync version that has su
On Fri, May 09, 2008 at 09:06:02AM -0400, Robert DuToit wrote:
> I havn't compiled 3.0.3 pre1 yet but have been seeing considerable longer
> backup times on OSX 5.2, using 3.0.2 over 3.0.1.
There is nothing in the changes for 3.0.2 would affect rsync's speed.
Perhaps the patches you applied diffe
On Sat, May 10, 2008 at 08:15:58AM +0200, Dominik Mahrer (Teddy) wrote:
> /usr/include/compat.h:22:2: warning: #warning "This header is obsolete, use
> ap_compat.h instead"
> /tmp/ccHr5d51.s: Assembler messages:
> /tmp/ccHr5d51.s:1409: Error: symbol `fstatat64' is already defined [...]
You might
On Thu, May 08, 2008 at 05:08:05PM -0700, Carl E. Thompson wrote:
> If this is the desired behavior of "--inplace" then the documentation
> is misleading at best.
Yes, the documention of that option was unclear that it was talking
about an update for a transferred file. I've checked-in some
impro
On Thu, May 08, 2008 at 09:34:07PM -0400, Matt McCutchen wrote:
> This is to continue my discussion with Carl [...] about whether
> no-tweak mode should become rsync's default when --inplace is not
> specified.
I completely reject this idea. The --inplace option is all about data
updating, not at
I have made rsync 3.0.3pre1 available for release testing. This is
another bug-fix release, with the only "enhancements" being some
improved terminology in the rsyncd.conf manpage and some improvements
in the testsuite.
To see a summary of the changes since 3.0.2, visit this link:
http://rsync
On Wed, May 07, 2008 at 06:25:36PM -0700, Carl E. Thompson wrote:
> This patch causes rsync to honor the absence of the "--inplace" option
> for permission, owner and group changes.
Unfortunately, that's not what the --inplace option is for. Its purpose
is to control how data updates occur, not a
On Mon, May 05, 2008 at 11:24:04AM -0400, [EMAIL PROTECTED] wrote:
> rsync -avzul -e "ssh -vvv -l username" /home/users/blah/
> rsync://lrem02:10001::/live
That tells rsync to start up a single-use rsync daemon on the remote
system after logging in via ssh. Daemon port numbers are completely
ign
On Mon, May 05, 2008 at 08:12:43AM +1000, Ramkumar Santoshi wrote:
> once i compile rsync, the 'rsync' in the current dir should be ok for this?
Right.
> can you please explain each step from then?
I listed the steps in the prior email, but here they are with a little
more detail:
Enable core d
On Thu, May 01, 2008 at 01:19:14PM +0200, Mi wrote:
> Is there a way to prevent rsyncd from doing reverse IP lookups on
> connecting clients? I didn't find any config option for this.
There is no such option in the rsync code. I'd suggest adding any
local-net entries to your /etc/hosts file so t
On Fri, May 02, 2008 at 12:38:12PM +1000, Ramkumar Santoshi wrote:
> I'm pretty sure i grabbed the one from the build dir. Is there any way i
> can tell?
You can look at the size and/or see if "file rsync" output "stripped" or
"not stripped".
..wayne..
--
Please use reply-all for most replies t
On Tue, Apr 29, 2008 at 10:05:07AM +1000, Ramkumar Santoshi wrote:
> On Mac OS10.4, using rsync 3.0, it stops during a transfer.
That's an incomplete version. The last release was 3.0.2.
> 2008/04/28 20:48:46 [3149] rsync: writefd_unbuffered failed to write 4 bytes
> [sender]: Broken pipe (32)
On Wed, Apr 30, 2008 at 02:21:20PM +1000, Ramkumar Santoshi wrote:
> When using rsync 3.0 to sync files between 2 local directories, it
> works as i expect it, but when the destination folder is a mounted smb
> share, it always copies over the files even though they already exist
> on the destinati
On Sun, Apr 27, 2008 at 11:06:00PM +0200, Karl Kashofer wrote:
> rsync calculates a md4 checksum of every file transferred. Would it
> be possible to store this checksum for future use, i.e. to recheck the
> files of each rsync snapshot at any later time ?
The "db.diff" patch in the latest source
On Thu, Apr 24, 2008 at 07:44:11AM -0400, Tim Evans wrote:
> Purpose of the entry is to exclude any directory or subdirectory named
> "TMP" from backup via rsync, but it's not doing it. What am I doing
> wrong?
I can only makes guesses:
If you have some dirs that differ in case, try this:
- [Tt
On Fri, Apr 18, 2008 at 08:42:28AM -0700, Nittany Jim wrote:
> The source file is 36412008 bytes (I confirmed this), yet rsync thinks
> it is 38595728 bytes.
The total file size comes from the sum of all the st_size values
returned by stat(). If it is inaccurate, I'd suggest checking if the
value
On Sun, Apr 27, 2008 at 12:11:47AM -0600, lewis Eklund butler wrote:
> Is there some way to do this so that all the files rsync backs up get
> compressed?
See the mail archives for prior discussions on compressed files for a
reference to a patch that can be used for this (though I don't recommend
On Sat, Apr 26, 2008 at 10:33:42AM +0200, Paul Slootman wrote:
> I just got this bug report about rsync 3.0.2 reproducibly crashing,
> together with a backtrace and a patch; very helpful :-)
Yes, quite helpful. The fix is indeed the right one, though we can
avoid the re-indenting of all that code
On Thu, Apr 17, 2008 at 12:57:27PM -0600, Kenneth Seal wrote:
> I have tried running my script in verbose mode -vv but I really don't
> want to read all 1000+ lines of output to look for the error code.
Errors should be output to stderr, and it isn't required that you have
even one -v specified to
On Thu, Apr 17, 2008 at 09:42:03PM +0800, Gav wrote:
> expand file_list pointer array to 262144 bytes, did move
> I see this code is in flist.c, but why are we getting this
> and how to avoid it ?
That's not an error, that's an informational message. If you don't like
it, don't use such a hig
On Tue, Apr 15, 2008 at 02:06:28AM +0200, Ruediger Oertel wrote:
> patches/xattrs.diff repeats the man-page change from patches/slp.diff
> producing an error if you try to apply both patches.
I'm looking into why the change to rsyncd.conf.yo made in the slp patch
got added to all the patches that
On Wed, Apr 16, 2008 at 04:13:55AM -0700, zahed wrote:
> Can anybody tell me how to send data from the generator to the receiver.
There is not currently a data path from the generator to the receiver
except going through the generator. The only pipe between the two
allows data to be sent to the g
On Tue, Apr 15, 2008 at 11:45:35PM +0200, Hans-Dieter.Doll wrote:
> This worked fine for me at least up to rsync version 2.6.2.
> Now I'm trying to use this on SuSE SLES 10 which has rsync version 2.6.6
> and the server rejects all files with the error message
> "skipping server-excluded file".
St
On Wed, Apr 16, 2008 at 06:51:37AM +0200, Ph. Marek wrote:
> So I'd need a clear indication whether source and target are identical
> - files (incl. mtime!), symlinks, devices, directories, everywhere
> owner, group, and mode, and in the near future possibly xattr too ..
That's what -i is for. I
On Tue, Apr 15, 2008 at 02:05:00AM +0200, Ruediger Oertel wrote:
> fails (most of the time) in the itemize test:
That is only true if rsync is compiled to think it can change the time
on a symlink and sometimes it can't. Either ignore that particular
failure, or comment-out HAVE_LUTIMES in config
On Wed, Apr 09, 2008 at 04:19:42PM +0100, Paul Reilly wrote:
> I've compiled a fresh copy of rsync 3.0.2 (version info below) on
> MacOSX Leopard Server 10.5.1 and am doing an rsync of the whole
> system like this: [...] It works OK, but returns with a failure error
> code, and the following error
On Tue, Apr 08, 2008 at 01:05:28PM -0400, Robert DuToit wrote:
> I only use the fileflags and crtimes patches. Can I just use them from
> the patch files directory released with 3.0.1, on 3.0.2?
The patches tar download is there for those that need it, just like
normal (though the patches didn't c
I have released rsync 3.0.2. This is a security release to fix a
potential buffer overflow in the extended attribute support. For
more details, see the rsync security advisory page:
http://rsync.samba.org/security.html
There is a patch there that can be applied to 2.6.9 (if you were using
the
On Tue, Apr 08, 2008 at 10:16:05AM +0200, Marco Bridge wrote:
> I mean, rsync seems to be arbitrarily changing filenames
No, rsync doesn't change filesnames at all. You should be looking for
external reasons for the inconsistencies, such as inconsistent case in
the source filename arguments (when
I have released rsync 3.0.1. This is a bug-fix release, which also
includes fixes/improvements for several issues in the daemon-exclude
code.
To see a full summary of the changes since 3.0.0, visit this link:
http://rsync.samba.org/ftp/rsync/src/rsync-3.0.1-NEWS
You can download the source ta
On Tue, Apr 01, 2008 at 11:12:03PM -0400, Matt McCutchen wrote:
> Thanks, but I noticed that you mangled the specifics on what HFS+ does.
I used the values rsync reported in the original email describing the
copying problem. I'll see if I can test the actual functioning.
..wayne..
--
To unsubsc
On Tue, Apr 01, 2008 at 03:01:39PM -0400, Matt McCutchen wrote:
> the Mac OS X HFS+ filesystem has an annoying behavior of silently
> decomposing UTF-8 characters in filenames.
Ah yes, good point. I bet you're right about that.
> Wayne, please consider adding this material to the "copies every f
On Mon, Mar 31, 2008 at 10:48:18AM +0200, Sebastian Kösters wrote:
> On the sun the command (in ps ef) went away after about 2 Minutes with
> the error message I sent you.
That makes it look like a connection failure then. Perhaps a firewall
is closing an idle connection? e.g. I once had a Links
On Mon, Mar 31, 2008 at 09:54:16AM -0400, Robert DuToit wrote:
> we tried adding option iconv=C and iconv=C,C but no luck
That would appear to be a request for rsync to not do any character
conversion, in which case you shouldn't be using --iconv.
When using the --iconv option, you should descri
I have released rsync 3.0.1pre3 for testing. This version contains a
couple more bug fixes since the 3.0.1pre2 release:
- Don't allow a daemon-exclude of .* or */ to affect a (vital) "." dir.
- Fixed a glitch in the path-checking of the daemon-exclude code that
could check a relative arg
On Sat, Mar 29, 2008 at 04:18:57PM -0400, Erik Jan Tromp wrote:
> I've done some experimenting locally & narrowed things down. In essense,
> I'm tripping over subtle changes in daemon exclude behaviour.
Thanks for figuring out what was going wrong. Rsync should not allow
the exclusion of a "." d
On Fri, Mar 28, 2008 at 04:41:26PM +0100, Sebastian Kösters wrote:
> 2008/03/28 16:35:46 [5573] rsync: writefd_unbuffered failed to write 4 bytes
> [sender]: Broken pipe (32)
This tells you that the connection unexpectedly closed, so you should
look to see why BackupPC went away.
..wayne..
--
T
On Thu, Mar 27, 2008 at 12:21:58PM -0700, Brian McGrew wrote:
> Looking at /usr/include/sys/syslimits.h on the Mac, PATH_MAX is defined at
> 1024 and then MAXPATHLEN is defined as PATH_MAX.
I'd suggest trying to create a really long symlink to see what the OS
maximum value is. If the OS allows a
On Thu, Mar 27, 2008 at 07:32:30AM -0700, Brian D. McGrew wrote:
> overflow: linkname_len=2751
Is there a symlink with a really long path in that
filevault/visionpro/release/4.7.2_fedora-LINUX-g/include/libinc dir?
The name must fit inside the system's MAXPATHLEN, and a link of 2751
bytes is appar
I have released rsync 3.0.1pre2 for testing. This version contains a
few more bug fixes since the 3.0.1pre1 release:
- Fixed a problem with the --iconv processing when a filename fails to
convert: the code no longer gets out of sync, and aborts.
- Fixed an assert failure in the hard-lin
On Wed, Mar 26, 2008 at 05:24:15PM -0400, Simo Sorce wrote:
> Is it ok to pass this kind of bug directly upstream filing a new bug in
> bugzilla and linking the fedora bug ?
Sure, that works fine. Posting a bug to the mailing list is also fine
especially when the bug is not going to linger in bug
On Wed, Mar 26, 2008 at 07:23:46AM -0700, Peter Heiss wrote:
> @ERROR: invalid gid admins
> I have "users" set as the gid in my rsync config file.
Search for the string "admins" in the config file. You presumably set
the gid in more than one spot, such as in the module's settings.
..wayne..
--
On Sun, Mar 23, 2008 at 07:54:09PM +0100, Sergi Baila wrote:
> 2008/03/23 19:27:37 [3760] received request to transfer non-regular file:
> 86300 [sender]
OK: thanks to Sergi's off-list debug info, I've fixed the problem. It
was caused by a name that failed to convert on the sending side, and
tha
On Mon, Mar 24, 2008 at 09:11:43AM -0400, Simo Sorce wrote:
> The notes say to use --no-d, but using it seem not to help, and in
> fact the remote host is still sent the 'd' option:
Yeah, the code was erroneously overriding the --no-d option, so I fixed
that in the latest version (see 3.0.1pre1).
I have just released rsync 3.0.1pre1 for release testing. This is a
bug-fix release, which includes fixes/improvements for several issues
in the daemon-exclude code.
Please test this new release and send email to the rsync mailing list
with any questions, comments, or bug reports.
To see a full
On Sun, Mar 23, 2008 at 07:54:09PM +0100, Sergi Baila wrote:
> 2008/03/23 19:27:37 [3760] received request to transfer non-regular file:
> 86300 [sender]
This means either that file-list number 86300 is not matching up between
the sender and the receiver, or that the data stream is somehow out of
On Sun, Mar 23, 2008 at 03:55:48AM -0700, zahed wrote:
> And could you tell me why do both receiver and generator have to
> receive the file list[?]
Because the files that the receiving side is reconstructing are those
of the sending side, so we need to know the state of the files on the
sending s
On Sun, Mar 23, 2008 at 11:51:08AM +0100, Andrea Righi wrote:
> Allow to change the block size used to handle sparse files.
Thanks. I've added a new patches file, sparse-block.diff, with your
patch (slightly tweaked).
I think that long-term we probably want to rewrite the sparse-file code
to hav
On Sat, Mar 22, 2008 at 02:06:02AM -0700, zahed wrote:
> The info that I am looking for is - "Are the files processed in the
> same order in both the receiver and generator processes?".
The generator controls the action. The receiver just reacts to the data
that arrives from the sender (which tel
On Fri, Mar 21, 2008 at 04:00:40PM -0700, Wayne Davison wrote:
> It may be possible to further conceal this.
The latest code now returns back proper errors for excluded path
elements, and does not truncate an arg with an excluded element.
The code handles both regular args and file-from a
On Tue, Mar 18, 2008 at 03:11:06PM -0400, Matt McCutchen wrote:
> rsync-dev -r -vi rsync://[EMAIL PROTECTED]:3141/module/./secret/ download/
This is now fixed.
> rsync-dev -r -vi --files-from=<(echo secret/) --no-R rsync://[EMAIL
> PROTECTED]:3141/module/ download/
I can think of 3 different wa
On Thu, Mar 20, 2008 at 07:19:14AM -0400, Robert DuToit wrote:
> A quick question. I tried --iconv=. but it didn't seem to work for my
> friend with umlautes in his file names.
Perhaps the default character set isn't set right for those filenames.
You can always specify the charsets explicitly.
On Thu, Mar 20, 2008 at 11:09:57AM +, Stuart Halliday wrote:
> Is it just me or a lot of people on this mailing list got into a bad habit
> of also carbon copying to the poster as well?
I always send the mail to the person I am replying to and Cc the list.
This is not a bad habit, but what I c
On Wed, Mar 19, 2008 at 10:13:38PM +0100, Olivier Thauvin wrote:
> I didn't said -e cause rsync server running a command, but in the case
> the server is setup to allow me to run rsync through ssh, I can rsync
> by hand 'ssh computer rsync -e'.
The nice thing is that there is no need to deny -e as
On Wed, Mar 19, 2008 at 10:11:52AM -0700, rdwyer wrote:
> Is there a way to absolutely prevent rsync from copying
> a specific file in a directory where every file but that one is to be
> copied?
One thing you can do to prevent a particular file from being transferred
is to give rsync an absolute-
On Sun, Mar 09, 2008 at 08:24:53PM -0400, Matt McCutchen wrote:
> I propose removing excluded_below. This would only make daemons that
> are already insecure more glaringly so, and it would have the benefits
> of simplifying the code and making any weaknesses in the daemon-exclude
> checking more
On Thu, Mar 13, 2008 at 11:01:35AM -0400, Ming Zhang wrote:
> Some time rsync just return error code 23 that some files are not
> transferred. Is there a way to get a list of these files so we can retry
> it later time?
The list of files was output on stderr during the copy. Rsync will try
them a
On Tue, Mar 11, 2008 at 03:00:25PM +0100, Giuliano Gavazzi wrote:
> rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32)
This just tells you that the receiver side went away, but we don't know
why it went away. If it is crashing, try to get a core dump and report
the back
On Thu, Mar 13, 2008 at 09:33:42PM +0100, jan wrote:
> -bash-3.1$ rsync -av --link-dest=20080313/
> --compare-dest=/data/BOC55/20080313/ 20080313/ /data/BOC55/20080314/
That set of options is impossible since you can't mix --link-dest with
--compare-dest. Back in the days of 2.6.3, rsync would si
On Thu, Mar 13, 2008 at 02:11:28PM +0200, Mark, Oren wrote:
> On both A and B I use the rsync daemon version and configuration.
See the rsyncd manpage for a discussion of the "use chroot" setting,
how it affects user-/group-name mapping, and what you can do about it:
http://rsync.samba.org/ftp/rs
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
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
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 thi
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
On Sat, Mar 08, 2008 at 11:53:50AM -0500, Matt McCutchen wrote:
> It turns out that just restoring the condition isn't enough,
> as rsync still incorrectly itemizes 'p' when -E is on and an
> alternate basis file differs from the destination file-to-be
> in permissions but not in executability:
Su
On Thu, Mar 06, 2008 at 08:46:03PM -0800, Kaleb Pederson wrote:
> Is it safe to allow 'e' if '--server' is also present?
Yes, that's completely safe. See also the latest support/rrsync program
for a validation script that already allows the special-use form of 'e':
http://rsync.samba.org/ftp
On Thu, Mar 06, 2008 at 10:38:37AM -0800, Mark Lavi wrote:
> Where is the signing key for rsync?
Here's an email that covers the issues:
http://lists.samba.org/archive/rsync/2004-January/008252.html
Note that these days I use "hkp:" instead of the "x-hkp:" prefix
mentioned in that 2004 message.
On Tue, Mar 04, 2008 at 06:20:21PM +0100, Paul Slootman wrote:
> The other issue in the bug report is something else, but as that happens
> when using 3.0.0 going to the 2.6.8 version running at rsync.net
It sounds like they're running something like the support/rrsync
validation script, which rem
On Tue, Mar 04, 2008 at 12:21:01PM +0100, Lasse Kliemann wrote:
> 'rsync -a' updates the ctime on a directory even if no file in that directory
> has changed.
Earlier rsyncs always did an extra stat() prior to setting the time, so
I've restored that behavior. The attached patch fixes this.
..wa
On Tue, Mar 04, 2008 at 06:25:12PM -0500, Matt McCutchen wrote:
> Wayne, this brings up a good point. It would be nice if each source
> package had a "persistent" URL that worked whether or not the version is
> the latest
Yeah, that's a good idea. I've organized the source (including the
latest
On Tue, Mar 04, 2008 at 07:07:07PM +0100, Paul Slootman wrote:
> If rsync is called with -4 or -6, that option is currently ignored when
> ssh is used as the transport.
That's because those options are only used when opening a socket. The
user should configure ssh on their own. I'd suggest that
On Tue, Mar 04, 2008 at 10:40:26AM -0600, Mike Bombich wrote:
> but this entire chunk of the that original diff file was lost:
Generated files are not included in the repository or its patches. They
are only included in the release tar. Those accessing the developer
source are expected to have t
On Mon, Mar 03, 2008 at 01:50:28PM -0800, Wayne Davison wrote:
> I'll fix the NULL and look to get a test for this added.
The git repository has both the fix and the extended test.
Attached is just the NULL-pointer fix.
Thanks for your help!
..wayne..
--- a/clientserver.c
+++ b/client
On Mon, Mar 03, 2008 at 09:16:46PM +0100, Paul Slootman wrote:
> The short story: it looks like client_info is NULL at compat.c:90, if I
> look at the strace and ltrace output supplied in the above URL.
No, looks like the problem is a NULL config_file var. If rsync had been
called with --rsync-pa
On Mon, Mar 03, 2008 at 03:34:30PM +0100, Paul Slootman wrote:
> If files that are shorter on the receiving side are skipped, how is it
> possible that rsync updates a file by appending data onto the end?
Thanks. That should say that files that are the same size or longer on
the receiving side ar
On Sun, Mar 02, 2008 at 08:48:45PM +0100, Axel Rose wrote:
> I was eager to test the fresh release with MacOS X using "bbouncer"
See the recent thread with the "congrats" subject that discusses this.
I mention an option you're missing (--force-change) and also post a
helpful patch. Also, the crea
On Sat, Mar 01, 2008 at 06:10:21PM -0500, Robert DuToit wrote:
> Verifying:bsd-flags ... FAIL
> Verifying: fifo ... FAIL
> Verifying: devices ... FAIL
I'm attaching a patch that adds the *_APPEND changes I mentioned and
also a fix for the sending of devices
On Sat, Mar 01, 2008 at 06:10:21PM -0500, Robert DuToit wrote:
> PS I did notice that we lost the bsd flags test in 3.0.
Hmm ... two items:
1. Tweak the rsync.h file to add the *_APPEND flags back to the
immutable defines (I had thought they weren't needed, but apparently
that is not the case):
On Sat, Mar 01, 2008 at 01:29:58PM -0800, Wayne Davison wrote:
> To see a full summary of the changes since 2.6.9, visit this link:
>
> http://rsync.samba.org/ftp/rsync/rsync-3.0.0pre10-NEWS
Sorry, I neglected to remove the pre10 from that link. The link on the
web site was (and
Yes, it's finally that time -- rsync 3.0.0 has been released. This is a
feature release that also includes quite a few bug fixes.
I'd like thank everyone who participated in the development and testing
of rsync. I hope that you enjoy this latest version!
The 3.0.0 version number is such a large
On Fri, Feb 29, 2008 at 02:14:20PM -0800, Juri Mianovich wrote:
> I lay awake at night wondering what would happen if
> someone plugged in a broken $destination, and my
> nightly rsync proceeded to delete everything on the
> destination ...
You can make your script validate the args before using t
On Fri, Feb 29, 2008 at 02:07:14AM -, Steven Hartland wrote:
> Attached is a slightly different patch which doesn't attempt chflags
> to every file, instead it catches the error case in robust_rename
> and only then calls chflags(to, 0)
I have already made a change in a similar vein to the off
On Thu, Feb 28, 2008 at 12:55:11PM +0200, [EMAIL PROTECTED] wrote:
> It would be good to add link to convmv script into rsync --iconv
> documentation. convmv can be found from http://www.j3e.de/linux/convmv/
Thanks. I have mentioned that utility on the rsync resources page.
..wayne..
--
To uns
On Thu, Feb 28, 2008 at 07:26:08AM -0800, Wayne Davison wrote:
> If someone else would care to fix that, I'll certainly consider it.
Actually, now that I'm thinking about it, I recall that I didn't like
some things in how the patch worked, and began to work on signficant
On Thu, Feb 28, 2008 at 08:18:26AM -0500, Matt McCutchen wrote:
> The distributed patch "drop-cache.diff" is an older version of this
> patch. Wayne, would you care to update it?
His updated patch ignored all the improvments that I put into to the
first patch, and I didn't feel like redoing them.
On Wed, Feb 27, 2008 at 02:07:06PM -0700, Rob Bosch wrote:
> If there is 100% match shouldn't it just leave the file as is even if
> the -I option is selected?
The -I option tells rsync to transfer all the files (ignoring any
quick-check time/size matches), so it is expected that it will update
th
On Mon, Feb 25, 2008 at 09:28:18PM -0700, Rob Bosch wrote:
> I reran this test with the --no-whole-file option and received the exact
> same results. Any idea on why some much data is being sent when the files
> are exactly the same on both sides?
Yeah, I hadn't noticed that your transfer had alr
On Tue, Feb 26, 2008 at 02:14:34PM +0200, [EMAIL PROTECTED] wrote:
> Has anyone got iso8859-1 to utf-8 conversion working with rsync-3.0.0pre10?
It was failing when communicating with a daemon due to a missing
setup_iconv() call. The attached patch fixes this. Thanks for
your report!
..wayne..
On Mon, Feb 25, 2008 at 11:14:19PM -0500, Robert DuToit wrote:
> I just tried (on OS10.5.2) the new fileflags.diff patch
>
> patch -p1 patch -p1 https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
601 - 700 of 2912 matches
Mail list logo
