Hasanat Kazmi wrote:
Hello,
I am looking into possibilities of porting RSync for windows. Does anybody
have an idea that which libraries and dependencies RSync uses which can not
be compiled on windows (so thats why we use cygwin)
I have not looked at this in a few years, but the issues is
Olivier Thauvin wrote:
Le Tuesday 5 July 2005 17:48, John E. Malmberg a écrit :
Olivier Thauvin wrote:
Currently there is no rsync library for rsync network function. the
librsync project provide functions for the file access/md4 part.
That exactly the reason why I just started a rewritten
Olivier Thauvin wrote:
Currently there is no rsync library for rsync network function. the librsync
project provide functions for the file access/md4 part.
That exactly the reason why I just started a rewritten of rsync using a struct
and to create a real library.
Current works is here:
Shachar Shemesh wrote:
John E. Malmberg wrote:
The I.P. address is listed in bl.spamcop.net as hitting spamtraps.
Just so you know, spamcop view bounces as spam. According to them, you
should never send bounces.
I think you will find a large amount of mail server administrators agree
Christian Nekvedavicius wrote:
Unfortunately I must report that legitimate emails are also blocked by
sbl-xbl.spamhaus.org.
If you e-mails are being blocked by a sbl-xbl.spamhaus.org listing then
you should be complaining loudly to your network provider.
It my help if you find out what list(s)
The file RSYNC.H always defines the macros SUPPORT_LINKS and
SUPPORT_HARD_LINKS.
#define SUPPORT_LINKS HAVE_READLINK
#define SUPPORT_HARD_LINKS HAVE_LINK
Everywhere that RSYNC uses SUPPORT_LINKS and SUPPORT_HARD_LINKS it is
testing if the macros are defined, not what their values are.
This
Martin Pool wrote:
John Van Essen wrote:
The policy is to block as much spam as possible without blocking
legitimate posts. A 100% solution is impossible, even if we had human
moderation (humans make mistakes).
I am seeing reports on news.admin.net-abuse.email from Steve Linford
that he is
Wayne Davison wrote:
On Sat, Feb 12, 2005 at 09:53:28PM -0500, John E. Malmberg wrote:
I don't see this. All the code in CVS uses #if to test the value of
HAVE_SOCKETPAIR.
I found the problem, one of the bugs in my first experimental pthreads
version is that it sometimes creates a file
Wayne Davison wrote:
On Sat, Feb 12, 2005 at 10:07:05PM -0500, John E. Malmberg wrote:
Rsync is not including this file, nor is there a feature test for this
header file in the configure phase, but rsync is using [int64 and
uint64].
Rsync is defining its own int64 (using a define, not a typedef
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
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]
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
Paul Slootman wrote:
On Sat 27 Nov 2004, John E. Malmberg wrote:
A static data structure is guaranteed to be initialised to zero...
Ok.
Shouldn't it more correctly be:
const struct sum_struct null_num = {0, 0, 0, 0, 0, NULL};
Perhaps more readable, but in no way more correct.
Putting the const
In the module generator.c, there is a static struct sum_struct null_sum
that is not initialized by any way that I can determine in the routine
write_sum_head.
Shouldn't it more correctly be:
const struct sum_struct null_num = {0, 0, 0, 0, 0, NULL};
This would also allow the declaration for
In the module HLINK.C, the routine hard_link_check() will not compile
with the SUPPORT_HARD_LINKS macro defined to be zero.
It appears that the code should be set to return either a zero or a one.
I am not sure which. The example below assumes zero.
-John
[EMAIL PROTECTED]
Personal Opinion
jw schultz wrote:
On Mon, Oct 27, 2003 at 03:39:37PM -0800, Tom Holton wrote:
I could not find this question anywhere, but I apologize if it is and I
just missed it.
Running an Alpha, OSF1 V5.1 1885
configure went fine.
compile failed:
See no documentation about EAI_MAX
And, looking in the
Tom Holton wrote:
Hi, thanks for the reply. I apologize for not having a clearer question.
I did know that EAI_MAX was in lib/addrinfo.h
I have been able to produce an executable by simply copying 4 lines from
lib/addrinfo.h into lib/getaddrinfo.c
#define EAI_BADHINTS12
#define EAI_PROTOCOL
jw schultz wrote:
On Tue, Oct 21, 2003 at 11:28:11PM -0400, John E. Malmberg wrote:
There are approximately 235 global and static variables in rsync, and
of those 105 are obviously never modified after the fork() takes place.
That may be the case for several of the others, like the 10 in batch.c
jw schultz wrote:
Sounds promising.
The pitfall you with rsync in threads is that rsync forks
with a COW expectation using a great deal of data set prior
to the fork. Some of that data is altered. In particular a
slew of global variables that must become thread unique when
modified or things
jw schultz wrote:
On Sun, Oct 12, 2003 at 12:38:40AM -0400, John E. Malmberg wrote:
I am trying to restart getting rsync to run on OpenVMS, and find a way
around the fork() issue, posibly using POSIX threads.
It occurs to me that i may have been overly encouraging in
my last followup.
Getting
jw schultz wrote:
On Sun, Oct 12, 2003 at 12:38:40AM -0400, John E. Malmberg wrote:
I am trying to restart getting rsync to run on OpenVMS, and find a way
around the fork() issue, posibly using POSIX threads.
It occurs to me that i may have been overly encouraging in
my last followup.
Getting
What is the status of rsync on Windows 2000?
I was looking to install it on my test system, and the download
directory has a readme file that says I need the cygnus gnu-win32 library.
The link refers me to the index page for cygnus, with no way to get to a
download area. A google search shows
Martin Pool wrote:
You describe a long-term solution in which spam-friendly ISPs are
gradually ostracised. I'm not quite sure I believe you that there is
a clear distinction, that bonafide ISPs are really able to stop spam,
and that being ostracised will ever really cut them off. But
Re: Per the discussions about spam on this list.
Sending a confirming message to an unregistered poster is not a good
idea. The return/reply-to addresses in spam is forged, and that is just
adding to some victims e-mail.
Filtering runs the risk that a legitimate message gets lost, and the
From: jw schultz [EMAIL PROTECTED]
On Fri, Jul 26, 2002 at 09:03:32AM -0400, Bennett Todd wrote:
2002-07-26-03:37:51 jw schultz:
All that matters is that we can represent the timestamps in
a way that allows consistent comparison, restoration and
transfer.
A very good statement indeed.
Lenny Foner [EMAIL PROTECTED] wrote:
jw schultz wrote:
I find the use of funny chars (including space) in filenames
offensive but we need to deal with internationalizations and
sheer stupidity.
Regardless of what you think about them, MacOS comes with pathnames
containing spaces
Martin Pool wrote:
On 22 Jul 2002, John E. Malmberg [EMAIL PROTECTED] wrote:
A clean design allows optimization to be done by the compiler, and tight
optimization should be driven by profiling tools.
Right. So, for example, glib has a very smart assembly ntohl() and
LZO is tight
Martin Pool wrote:
On 27 Jul 2002, John E. Malmberg [EMAIL PROTECTED] wrote:
A program serving source files for distribution does not need to be that
concerned with preserving exact file attributes, but may need to track
suggested file attributes for for the various client platforms
Qualities
1. Be reasonably portable: at least in principle, it should be
possible to port to Windows, OS X, and various Unixes without major
changes.
In general, I would like to see OpenVMS in that list.
Principles
1. Clean design rather than micro-optimization.
A clean design
OpenVMS has two main file systems, one is not case sensitive or case
preserving, the other is by default not case sensitive but is case
preserving.
Files are generally sorted in a case blind fashion.
How big of a problem is this going to be?
-John
[EMAIL PROTECTED]
Personal Opinion Only
--
[EMAIL PROTECTED] wrote:
Experts, feel free to jump on me for being wrong, but the forking, as i
understand it, is integral to the way rsync currently does its work, and i
don't think you can realy debug it in the classical sense. Anybody found
a way around this one?
A multi-process
Martin Pool wrote:
On 15 Apr 2002, John E. Malmberg [EMAIL PROTECTED] wrote:
I am trying to debug the RSYNC client and server by single stepping
through them.
The server seems to ok up to the point where it is waiting for the
client connection.
And then what?
I go to start up the client
Platform: Compaq OpenVMS Alpha 7.3
Compiler: Compaq C T6.5
The following patch resolves compile problems with the checksum.c module.
The type (char) was being used where the usage indicated either (void)
or (unsigned char) should be used.
The const qualifier was added to impove compiler
Sorry about the duplicate post of the batch.c patch. MOZILLA and ISP
network problems.
Platform: Compaq OpenVMS Alpha 7.3
Compiler: Compaq C T6.5
The type (char) was being used where the usage indicated (void) should
be used.
The const qualifier was added to improve compiler efficiency.
The following popt files need patches in order to compile using Compaq C
on OpenVMS. These patches should also be needed on a Tru64 or LINUX on
ALPHA using Compaq C. Except for the alloca issue, these should work on
any ANSI compliant compiler.
Operating System: OpenVMS ALPHA V7.3
The following zlib files need patches in order to compile using Compaq C
on OpenVMS. These should work on any ANSI compliant compiler.
Operating System: OpenVMS ALPHA V7.3
Compiler: Compaq C T6.5
Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE)
fnmatch.c and mdfour.c. Compaq C on
If SUPPORT_LINKS is not 1, the code should not be assuming the presence
of do_lstat or readlink.
Also syscall.c is testing macro definitions that may not be defined.
Operating System: OpenVMS ALPHA V7.3
Compiler: Compaq C T6.5
Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE)
-John
[EMAIL
Operating System: OpenVMS ALPHA V7.3
Compiler: Compaq C T6.5
Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE)
syscall.c is missing the const qualifiers for several of it's
functions. This patch should supercede the previous patch I submitted.
This was discovered while working on resovling
Dave Dykstra wrote:
On Tue, Jan 01, 2002 at 06:45:59PM -0600, John Malmberg wrote:
Compaq C 6.5
OpenVMS Alpha 7.3
...
A second issue, is the line:
#undef socklen_t
It is not in the standard format for the other lines in the configure
script.
It would be helpful for it to
39 matches
Mail list logo
