>
> Hi,
>
> I've got one thats really stumping me... rsync 2.6.9 from FreeBSD
> ports on both ends.
>
> /usr/local/tmp/rsync --dry-run -v -v -v -v -v -v -v -v -v -v -v -v --dry-run
> -vrlptHDgozxS --partial --force --delete --numeric-ids --exclude='A/*'
> --include='*/' /usr/local/etc/m
On Mon, 2008-02-04 at 18:27 +0100, Richard Taubo wrote:
> When quitting a rsync process (by e.g. typing: apple, period in OS
> X), where does rsync move the files that were being transferred?
> Are they /dev/null 'ed?
By default, the receiving rsync just deletes a partially transferred
file. Wi
On Tue, Jan 29, 2008 at 09:45:08PM -0500, Matt McCutchen wrote:
> Since the process executing the code inside the previous "if" (which
> doesn't close the log file) sets am_server = 1, I think the comment is
> backwards.
Yep, you're quite right. Sorry for the confusion in the first reply. I
real
https://bugzilla.samba.org/show_bug.cgi?id=5190
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, Feb 04, 2008 at 01:59:54AM +0100, Giuliano Gavazzi wrote:
> Running without -n transfers the file correctly.
That's the missing info I needed to fix the problem. There was a call
in the sender that was being run when it shouldn't have in dry-run mode.
The latest dev version (git, nightly,
On Sun, Feb 03, 2008 at 04:06:55PM -0700, Rob Bosch wrote:
> To bypass it I wanted to compile with the --disable-iconv function.
> I'm still getting the following errors during compile: [...]
The --disable-iconv configure option just disables the --iconv rsync
option. It does not disable all use
Hi!
When quitting a rsync process (by e.g. typing: apple, period in OS
X), where does rsync move the files that were being transferred?
Are they /dev/null 'ed?
Thanks!
Best regards,
Richard Taubo
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before post
On Mon, Feb 04, 2008 at 03:53:07PM +0100, Paul Slootman wrote:
> int key64 = (tbl->node_size > sizeof (struct ht_int32_node));
Aha! I had been unable to duplicate the problem, but that's because
that check only fails on a 64-bit architecture. I've just checked-in
a fix. Thanks for finding t
On Mon 04 Feb 2008, Paul Slootman wrote:
> value, and then it works. This looks like an attempt to save space,
> using 64 bits only when necessary. However the test seems flawed...
Adding some debug stuff shows:
hashtable_create(size=512, key64=1)
sizeof (struct ht_int64_node)=16, sizeo
It appears that the problem is not directly related to inode number
size, but to the way they are hashed to detect the same inode numbers.
If in hashtable_find() I change the following definition:
int key64 = (tbl->node_size > sizeof (struct ht_int32_node));
to:
int key64 = 1;
then the
On Sat 02 Feb 2008, Paul Slootman wrote:
>
> The files with 3239109xxx inodes aren't getting hardlinked.
> Note that this is still less than 2^32, so should fit in an unsigned 32 bit
> int.
> Note also that on large (>1TB) XFS filesystems on 64bit systems, a mount
> option "inode64" is recommende
On Mon, Feb 04, 2008 at 03:55:42PM +1100, Anthony Morton wrote:
> Incidentally, it seems the latest flags.diff still has some inconsistencies
> between '--flags' and '--fileflags': there are some five instances of the
> former that need to be replaced with the latter (or should it be the other
>
12 matches
Mail list logo
