looking into this a bit more, FreeBSD already has a strlcpy() function in libc:
==
NAME
strlcpy, strlcat -- size-bounded string copying and concatenation
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <string.h>
size_t
strlcpy(char * restrict dst, const char * restrict src, size_t size);
size_t
strlcat(char * restrict dst, const char * restrict src, size_t size);
==
The following patch gets me past this point:
*** rsync.c.orig Thu Jul 16 03:56:31 2015
--- rsync.c Thu Jul 16 03:56:55 2015
***************
*** 49,54 ****
--- 49,55 ----
*
* @return index of the terminating byte.
**/
+ #ifndef __FreeBSD__
static size_t strlcpy(char *d, const char *s, size_t bufsize)
{
size_t len = strlen(s);
***************
*** 61,66 ****
--- 62,68 ----
}
return ret;
}
+ #endif
/* splits filepath at the last '/', if any, like so:
* dirname basename filepath
> On Jul 15, 2015, at 18:34, Marc Fournier <[email protected]> wrote:
>
>
> Anyone have any experience / luck building it on FreeBSD 10.x?
>
> ==
> gmake all-am
> gmake[1]: Entering directory '/usr/local/src/csync2-2.0'
> cc -DHAVE_CONFIG_H -I. -D'DBDIR="/usr/local/var/lib/csync2"'
> -D'ETCDIR="/usr/local/etc"' -I/usr/local/include
> -I/usr/local/include/p11-kit-1 -Wall -I/usr/local/include -MT rsync.o -MD
> -MP -MF .deps/rsync.Tpo -c -o rsync.o rsync.c
> rsync.c:52:15: error: static declaration of 'strlcpy' follows non-static
> declaration
> static size_t strlcpy(char *d, const char *s, size_t bufsize)
> ^
> /usr/include/string.h:93:9: note: previous declaration is here
> size_t strlcpy(char * __restrict, const char * __restrict, size_t);
> ^
> rsync.c:120:27: warning: size argument in 'strlcpy' call appears to be size
> of the source; expected the size of the destination [-Wstrlcpy-strlcat-size]
> strlcpy(temp,path,strlen(path));
> ~~~~~~~^~~~~
> rsync.c:120:20: note: change size argument to be the size of the destination
> strlcpy(temp,path,strlen(path));
> ^~~~~~~~~~~~
> sizeof(temp)
> 1 warning and 1 error generated.
> Makefile:552: recipe for target 'rsync.o' failed
> gmake[1]: *** [rsync.o] Error 1
> gmake[1]: Leaving directory '/usr/local/src/csync2-2.0'
> Makefile:385: recipe for target 'all' failed
> gmake: *** [all] Error 2
> ==
>
>
>
>> On Jul 15, 2015, at 14:57, Lars Ellenberg <[email protected]> wrote:
>>
>> On Tue, Jul 14, 2015 at 08:47:38PM -0700, Marc Fournier wrote:
>>>
>>> Am working on using csync2 to backup remote servers to a central server …
>>> am using csync2 mainly because of the efficient way that it uses a local
>>> database to minimize the network traffic, as well as load on the ‘backup
>>> file system’
>>>
>>> now, I have a file that I’m trying to send across that is ~700M, and am
>>> gettign a ‘remote closed connection’ before it finishes … doing a bit of a
>>> search on the remote server, I’m finding tht /tmp is filling up fast, but
>>> there are no files in there that is growing, so figure its doing something
>>> that isn’t “visible” on that file system … and /var/log/messages verifies
>>> that:
>>>
>>> kernel: pid 23073 (csync2), uid 0 inumber 33 on /tmp: filesystem full
>>>
>>> Now, reading the docs, I see that there is a tempdir setting, but its
>>> recommended not to use it, and it states that it creates temp files in the
>>> order of ‘tempdir, same directory as currently processed file, directory
>>> given by TMPDIR variable, etc’ …
>>>
>>> so first question is, why is it creating it in /tmp (which, according to
>>> the docs, is pretty much the *last* think it will try) vs ‘same directory
>>> as currently processed file’ (that directory has 480G of disk space
>>> available) …
>>>
>>> I can set tempdir to the same file system as the final file will be put,
>>> but from what I’m reading, I shouldn’t need to …
>>>
>>> please advise …
>>
>> Use recent versions of csync2 (2.0).
>>
>> That no longer uses /tmp/, or at least only uses it as fallback,
>> but tries to create temp files next to the original (similar to rsync).
>>
>> See also the section on "tempdir" (which you should not use) in
>> http://oss.linbit.com/csync2/paper.pdf
>>
>> --
>> : Lars Ellenberg
>> : http://www.LINBIT.com | Your Way to High Availability
>> : DRBD, Linux-HA and Pacemaker support and consulting
>>
>> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
>> _______________________________________________
>> Csync2 mailing list
>> [email protected]
>> http://lists.linbit.com/mailman/listinfo/csync2
>
_______________________________________________
Csync2 mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/csync2
