Re: Possibility to porting Rsync to NT and other platforms
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 more that rsync initializes some data structures and then forks off processes. But it is doable. I make an experimental proof of concept port where I converted it to use posix threads instead of forked processes. With the code base that I worked on, the main thing was identifying which of the common or static variables are modified by more than one thread. The experimental version was working well enough that I could keep a local copy of the rsync source code in sync on my system with it. I had set up a system to use editor macros to re-apply my changes to the lastest source, but had to move on to other things before I completed the port. I currently use the experimental port binary several times a week for keeping my system up to date with blead-perl source. Good Luck, -John wb8...@qsl.net Personal Opinion Only -- Please use reply-all for most replies to avoid omitting the mailing list. 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 lib
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 of rsync using a struct and to create a real library. It is a cvs co made recently, true. Rsync code use many global ans static variable, this is not usable for a library. So to done a lib, I took rsync, create a struct and it's typedef (see rspeer.h and rspeer.c) and I am removing all global/static variable from code to put it inside the rspeer struct. There are about 300 to 400 global or static variables in rsync. Of these, about 75% appear to be set at startup and only read by the other processes that are created. Another group of them are only used by a single process ever. The current code doesn't works and doesn't compile at time, notice I start this one or two weeks ago and I still have to modify all function to pass the rspeer struct as argument: -int allow_access(char *addr, char *host, char *allow_list, char *deny_list) +int allow_access(rspeer rsp, char *addr, char *host, char *allow_list, char *deny_list) Since I was not looking at using this in a reentrant library, I took the approach that only a integer thread index was needed to find the correct variable. And only the variables that were used by more than one process after the additional processes were forked needed to be changed. I probably do not have all of the variables classified correctly yet. It would help if their names were tagged for their use or a comment on them. I am told from this list that only three processes are active, and in getting the just the client to work, I am seeing only two. So I only need an array of three structures which I set up as a static. So I still have to find out what the third process is used for and how to do the same on OpenVMS with out a fork() routine. A routine could get the thread index by either by having it passed as a parameter, or could make a POSIX thread call to find it out. A library could use a process id also as an index for storage maintained internally, with some care for garbage collection. On UNIX it appears that each image is run with it's own process id. On OpenVMS that is not the case, so a different method is needed to detect that the calling image exited with out cleaning up. By having many of the routines like write_int() look up thread index instead of getting it passed, it significantly reduces the amount of source code that needs to be changed or changes that need to be tracked. In many cases, only the top of the files need to be changed. As per your example, access.c that contains allow_access is one of the routines that I did not need to change at all, since it never references any of the global variables directly or has any local static variables. Compiler macros are also used to minimize the code changes. For example: int am_sender; is a member of a structure of global thread specific variables. When I compile for POSIX threads, a macro gets defined: #define am_sender main_global[thread].am_sender So none of the references in the code to am_sender need to be changed. These macros and structures reside in one module thread_global.h I have an interest in such a project as the normal user interface for OpenVMS is a bit different than on UNIX. In order for me to use such a library, all routines must be thread safe, and allow a single process to do the work. I currently do not plan to change rsync code else for making code works from library, but I am in the first step of the project, and open to all improvements/suggestion. I am open to any help to. See http://encompasserve.org/rsync_pthread_pre.zip. This is a gnu unified diff between a snapshot taken today of the rsync source + some additional files. The files *.gdiff are difference files, the *_xxx.new files need to be renamed *.xxx. The resulting files with *_vms_*.* or *.com, *.mms are only for OpenVMS use. Some routines now take an integer thread parameter, others look it up. I also made some changes as ANSI C will not allow unsigned char and char types to be mixed with out a cast, and fixed some other things that VMS will need. The resulting code with the macro USE_PTHREADS defined currently compiles and links on my OpenVMS 8.2 system. It will probably not run with USE_PTHREADS because I still have to write the routine that looks up the thread index. This is a thread index number that I will assign to a thread when it starts as I can not predict what the actual thread number would be. I also have to add code to set the stack size for each thread. By default on OpenVMS Alpha, only an 8K stack per thread is allocated, and that is not enough for rsync. With out that macro defined, it should build on a UNIX/LINUX system
Re: rsync lib
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: http://nanardon.homelinux.org/cgi-bin/viewcvs.cgi/rsync-ng/?root=Nanar But this need lot of works... From a quick look, this looks like a snap-shot of one of the rsync releases. I have an interest in such a project as the normal user interface for OpenVMS is a bit different than on UNIX. In order for me to use such a library, all routines must be thread safe, and allow a single process to do the work. OpenVMS has two options for using such a library, one is using Posix Threads, and the other is using a native asynchronous I/O for network and terminal and disk access. -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: Spam to this list
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 with that, especially the ones that have been DDOS from spammers and viruses impersonating their domain. A few years ago I saw a posting in the spamcop.net forum reporting that AOL had posted in the SPAM-L mailing list that AOL was changing their system to only use SMTP rejects and that they were going to stop generating bounces because they recognized that the practice is abusive to the rest of the internet. Spamcop.net only changed their policy a few months ago. Spamhaus.org has also listed I.P. addresses that are bouncing all detected spam and viruses. As near as I can tell, they started doing before spamcop.net did, and it seemed to be triggered by a company selling an anti-spam/virus appliance that was configured by default to abusively bounce detected spam and viruses to what was known to be forged addresses. At least one domain, test.com was basically DDOSed to death for a while because of the bounces from spammers and viruses forging addresses. I believe the right approach is to convince admins to drop spamcop from their RBL list, rather than remove the very essential NACK SMTP has from all servers, as per spamcop's request. The essential SMTP NACK is not what is the problem as long as it is done during the SMTP connection using reject codes. Issuing a SMTP reject code for undeliverable messages will never cause a spamcop.net listing. The SMTP bounce is an artifact from the time when third party open relays where also in common use. At that time, it was needed by the third party open relay to return the non-delivery message. The end mail server would use an SMTP reject, and the third party open relay would generate the bounce message. Now, almost no mail servers will accept e-mail from known open relays, so when they can not deliver an e-mail, if they use an SMTP reject code, then the sender's mail server, which should trust the sender will generate the bounce message. If these bounces from the sender's mail server are going to forged addresses, then there is a security problem on the sending network that needs to be fixed. With almost all spam and viruses, there is no mail server to generate bounces from getting an SMTP reject. At current estimates on internet, a mail server is now getting 3 spam/virus messages for every real message that is attempted to be delivered. Which means if a mail server is bouncing instead of using SMTP rejects, it is bounce relaying 3 spam/virus messages for every real one, and those messages are being bounced to other victims. And since medium to large networks pay a metered rate for their internet connection, bouncing instead of using SMTP rejects will significantly increase their operating costs as it will cause them to pay for the bandwidth for 6 spam/virus e-mails for every 1 real e-mail that they receive. Using SMTP rejects and DNSbls eliminates almost all of that cost from their operation. -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: Spam to this list
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) that the I.P. address that is being listed is really on. The sbl-xbl.spamhaus.org is combination of three lists: sbl = sbl.spamhaus.org xbl = opm.blitzed.org and cbl.abuseat.org To get on the sbl portion, an internet provider has either had to work at being a bad network citizen and have been ignoring legitimate abuse complaints or is actively and knowingly assisting a spammer. The sbl is very conservative and will only list a production mail server as a last resort. To get on the opm.blitzed.org means that I.P. address has recently been tested and confirmed to be an open proxy, which basically means that it is providing unlimited free e-mail and other network services to every criminal on the internet. opm.blitzed.org will retest on request. To get on cbl.abuseat.org, the I.P. in question must have sent e-mail to a spamtrap address, and the contents of that e-mail was determined not to be from an auto-responder that is generating a new mail in response to spam or a virus. About the only way to get on the cbl.abuseat.org is for the I.P. listed to either be controlled by a virus or controlled by a spammer through an open proxy. Removal from the cbl.abuseat.org is done through a webform, one removal is allowed per week. So about only way that a mail server can get on the sbl-xbl.spamhaus.org is if it is under the control of a virus or a spammer. Now looking at the mail server that your post went through: It is not listed in the sbl-xbl.spamhaus.org. opm.blitzed.org claims that they have never listed the I.P. address and have never been requested to do a test on that I.P. address. The cbl.abuseat.org also shows that is is not listed currently. No other information is available. The I.P. address is listed in bl.spamcop.net as hitting spamtraps. There appears to be 5 outgoing mail servers for that domain, and that means that currently you have a 20% chance of your mail being rejected if you mail someone whose postmaster is using the spamcop blocking list for rejection instead of scoring. At least three of the mail servers have recently sent spam to spamtraps operated by the opm.blitzed.org. This caused proxy tests to be performed on them which they passed. 195.202.32.15 listed in bl.spamcop.net (127.0.0.2) If there are no reports of ongoing objectionable email from this system it will be delisted automatically in approximately 21 hours. Causes of listing Maximum listing time after the last spam report is 48 hours. Minimum listing time is 1/2. The time between varies based on an algorithm that takes into account prior listings of that I.P. address, and the amount of spam reported from it. * System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence are provided by SpamCop) To get listed this way, it means that the amount of spam hitting spamcop.net spamtraps exceeded 1% of the volume of e-mail from that I.P. from various monitoring points on the Internet. For an ISP mail server, 1% is usually a large number. Senderbase is reporting measuring well over 10,000 e-mails per day from that I.P. Additional potential problems (these factors do not directly result in spamcop listing) * System administrator has already delisted this system once Because of the above problems, express-delisting is not available Listing History In the past 17.7 days, it has been listed 3 times for a total of 38 hours For a production mail server to get listed by spamcop.net this many times in that short of time, it indicates that there is a problem at that mail server, either it is relaying spam, or it is abusively bouncing spam and virus reports to what are known to be forged e-mail addresses instead of following the standard practice and using SMTP rejects. Or they have a clueless user that is using the fake bounce function that some poorly written anti-spam software has. Of course they would have had to bounce a lot of spam/viruses in a short time to cause a listing. Sending bounces or virus notifications to forged addresses are effectively a denial of service attack against the user that the spam or virus impersonated. It looks like someone delisted the I.P. address from the spamcop.net list with out fixing the problem that resulted in the listing. Getting an ISP mail server listed on spamcop.net is also rare, but does happen, but generally there is a large period of time (Think months/years) between listings unless there is a chronic problem with the configuration or security of that server. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before
Can not build with out support for hard or symbolic links.
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 results that the code will always be built with support for hard and symbolic links. -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: Spam to this list
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 getting at least 99% accuracy in removing spam with zero loss of real e-mail. He is removing about 85% of the spam with DNSbls so that it does not even get inside of the mail server, and then using SpamAasssin 3.0 with it's new test on URLs inside of mail, where if the URL resolves to an IP address that is known to be controlled by a spammer, the e-mail is rejected. And he is reporting that he is not using a DHCP list for doing rejections. The first one has been in the dul.dnsbl.sorbs.net blacklist since Oct. I use these 4 DNS-based blacklists in the mail server that I manage: sbl-xbl.spamhaus.org I have not ever seen a report of an incorrect listing in the xbl.spamhaus.org. I have only seen one reported error in several years of the sbl.spamhaus.org and it was corrected with in 1/2 hour of this being pointed out on news.admin.net-abuse.email. It is a merging of 3 dnsbls for convenience. sbl.spamhaus.org - Hand maintained list of I.P. addresses controlled by spammers. The sbl.spamhaus.org is probably now the most widely used dnsbl in the world. An ISP has to work hard at supporting spam to get any of it's IP addresses listed in the sbl.spamhaus.org. xbl.spamhaus.org is a combination of opm.blitz.org and cbl.abuseat.org. The cbl.abuseat.org runs spamtraps that filter out auto-responders. In the time it has been in existence, I have seen zero reports of an incorrect listing. It will delist on request once per week, and listings age off. The opm.blitz.org verifies that the I.P. address is an open proxy, and ages off old listings. list.dsbl.org This is a list of known compromised I.P. addresses where no responsible party has demonstrated they have an RFC compliant mailbox set reading abuse complaints. If a real mail server is listed, it means that it is either an active compromised machine, or that their is no one that is reading messages to their abuse or postmaster e-mail addresses. It is extremely widely used to reject e-mail, possibly the most used after the spamhaus.org. dul.dnsbl.sorbs.net In the past, the dul.dnsbl.sorbs.net used to run a higher false positive rate. Now it is almost not measurable. dul.dnsbl.sorbs.net now allows owners of mistaken static entries to use a webform to remove them as long as they can show a forward DNS name pointing to that I.P. with a long enough TTL to show it is static. Currently a listing in dul.dnsbl.sorbs.net indicates well over a 99% chance of spam. web.dnsbl.sorbs.net I have heard nothing good or bad about that one. In the spam I sent through spamcop.net in the past year, I recall seeing it only flag one spam that was not detected by either the cbl.abuseat.org or njabl as being in that DNSBL. From what I have seen, the only zone in sorbs that is likely to cause real e-mail to be rejected is the spam.dnsbl.sorbs.net as it is usually listing multi-hop exploits of the mail servers of major ISP's and they have to jump through hoops to get off of it. The other SORBS zones do not require such extra actions. And they have helped a LOT. The other 3 have no reverse DNS entries. A machine with no reverse DNS that is sending email is not very likely to be a legitimate email server. It's much more likely a compromised machine on a clueless ISP's network. Rejecting email from those unidentified machines also has helped a lot. Using any of those measures alone tends to block legitimate posters, Can you find a legitimate post that was blocked by the sbl-xbl.spamhaus.org? I have not heard of an error on that list yet. From the reports that I have seen on the various e-mail forums, reverse DNS is now an RFC requirement for operating any server on the public internet. Networks with no rDNS are demonstrating that they do not understand how to be properly connected to the internet and have proven to be a large source of problems. The fastest way to get that problem fixed is to take AOL's approach and refuse all e-mail with no rDNS on it at all. particularly those running their own mail server, which to my mind is a greater harm than letting ocassional spam go through. Our purpose here is to run a mailing list, not punish ISPs. So we use all the things you named as part of a weighted score. Actually what is a result is that you are allowing the list recipients to be punished by incompetent ISP's. At some point, it is not worth attempting to try to find a potential real e-mail from a network that has allowed spammers to infest it by either neglect or by willful act. If you can put a [SPAM?] tag on mail trapped by a the following algorithm, I would be surprised if any real postings
Re: macro feature tests in rsync code
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 with the wrong contents. In this case it was trimslash.c containing some older code. I hope to have a better version running soon, as I was about 80% done with isolating the thread specific variables before rsyncing up with the current tree. 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: Possibly, but I do not use GCC. I have a similar option to disable these message and I have done so. It it just that IMHO, it would be better to have the code test to see if macros are defined and always issue diagnostics about undefined macros. -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.
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), so it is not depending on these fairly new types being found on the system (also, I thought they were really int64_t and uint64_t, but I could be wrong). That is what the standard types are. That define int int32 did not happen on my system for reasons that I have not yet determined. I discovered it when the compile failed. They do not seem to be new types, but common older non-standard types. It would probably be a good idea to add a test to configure to look for int64_t and make use of it, if necessary (with an appropriate include of inttypes.h or stdint.h, which configure already checks for, but rsync.h doesn't currently use). The latest code no longer uses uint64. int8, int16, int32, int64, etc... on my system are in the header file ints.h. As near as I can determine from google: For BEOS those definitions are in support/SupportDefs.h For HP-UX those definitions are in model.h Linux also seems to have ints.h. At the present time, I do not have quick access to inspect the contents. -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
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: Uninitialized static structure in generator.c/write_sum_head
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 qualifier on that variable allows the const qualifier
to be put on the sum parameter.
This allows the compiler to better optimize the code for the modules
that call write_sum_head().
In any case for the purposes of porting RSYNC to Posix Threads means
that this is not a thread specific variable.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Uninitialized static structure in generator.c/write_sum_head
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 the write_sum_head routine to
be as below, since the data that sum is pointing to is never modified.
void write_sum_head(int f, const struct sum_struct * sum)
-John
[EMAIL PROTECTED]
Personal Opinion Only
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
build bug: HLINK.C
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 Only
int hard_link_check(struct file_struct *file, int skip)
{
#if SUPPORT_HARD_LINKS
if (!hlink_list || !file-link_u.links)
return 0;
if (skip !(file-flags FLAG_HLINK_EOL))
hlink_list[file-F_HLINDEX] = file-F_NEXT;
if (hlink_list[file-F_HLINDEX] != file) {
if (verbose 1) {
rprintf(FINFO, \%s\ is a hard link\n,
f_name(file));
}
return 1;
}
#endif
return 0;
}
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: simple compile
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 code, indeed, EAI_MAX (et. al.) are not defined anywhere! It is defined in lib/addrinfo.h and included from rsync.h For DECC on OpenVMS, the symbol EAI_ADDRFAMILY is defined in netdb.h, and if netdb.h gets included before lib/addrinfo.h, then lib/addrinfo.h will not define those symbols. This may be the same for OSF1 on Alpha. How should I handle this? I do not know for OSF1 on Alpha. But now that you know what is happening, maybe you can figure out a workaround. For OpenVMS, I have the program that generates config.h put in the config.h file a #include vms_config.h. In the vms_config.h I put all the manual fixups. In the vms_config.h I put the missing definitions for the EIA symbols that were compatable with the existing EIA symbols supplied by the operating system. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: simple compile
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_PROTOCOL13 #define EAI_MAX 14 #define AI_MASK (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST) but I am guessing that this is not the preferred solution. I am assuming linux compilers or gcc do not get this problem, so I thought it might by important to have a correction for this on oSF. OSF1 on ALPHA is one of the previous names for what is now Tru64 UNIX, so what you are running is very old. It was named DIGITAL UNIX for several years before Compaq and Digital merged. Compaq changed the name to Tru64. I have not tracked the timeline for it closely, but the last time it was called OSF1 has got to have been about 5 years ago or longer. Ancient time in computer versions. It probably predates the getaddrinfo() call. If your version of DEC C is the same age as your OS, it is probably also ancient. Newer versions have better optimizers, error diagnostics and compliance with the C standards. If this qualified for a non-commercial hobby/educational license, you can upgrade to the current version for $99.00. http://h30097.www3.hp.com/noncommercial-unix/buy.htm Other than than occasionally doing battle with a LINUX or other UNIX systems, I do not know much about UNIX and rely on the expertise of others. I am trying to get rsync running on OpenVMS. On OpenVMS, the hobbyist license is free, and it includes the license for the DEC C compiler, code profilers, and other develoment tools. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync on OpenVMS
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 As the use of the remaining ones are identified, that issue is easily fixed. What I need to do is map the routines called by the receive process/thread to see what static/global variables that they modify. If you put the ones that get modified post-fork into a thread-local structure there is a reasonable chance of that getting into mainline. Now what would be more acceptable: Adding a context parameter to all the routines that reference the global/static variables that are currently shared? or Having each routine that uses those type of variables to go through the work of determining which thread that they are in? It seems to me that adding the context parameter would make it easier to maintain, and have a lower overhead. It also saves having thread lookup calls added to the routines. In some other cases, it looks like the sharing should not hurt, but their should be some synchronization. Since there are only two processes or threads that need to be tracked, while the parameter could be a pointer to global structure, it can be disruptive to put all the local thread specific static values in that structure. Mainly because a lot of them have the same symbol names, just different scope. So there could be a global variable that is void * recv_context, and a void * send_context for the sender for completeness. A routine that needs separate local static variables would check the context parameter passed to it against one of those pointers, and then use the appropriate set of local variables. With this, the static variables would become an array, and the context parameter would determine if index 0 or 1 was used. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync on OpenVMS
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 will break in subtle ways. Yes, I can see a few cases of this. 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 As the use of the remaining ones are identified, that issue is easily fixed. What I need to do is map the routines called by the receive process/thread to see what static/global variables that they modify. All the more reason to get more people working on this that want it to work on the OpenVMS operating system. Several people have contacted me that they are willing to assist. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync on OpenVMS
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 rsync to work using threads, whether pthreads or a superior form, will require enormous intrusive changes to the code. While my testing is far from complete, and I have a few OpenVMS specific things to work out, it appears that the changes to make the client use pthreads were minor, and as of yesterday a client on OpenVMS is able to properly replicate a sample directory of plain text files from a local server running rsync on Windows 2000. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: rsync on OpenVMS
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 rsync to work using threads, whether pthreads or a superior form, will require enormous intrusive changes to the code. I do not know but if OpenVMS support is a problem for rsync proper you might wish to look at pysync or unison which might meet your immediate needs. I have not heard of unison. I have heard that pysync was successful in a limited test on OpenVMS. As near as I can tell though the librsync it is based on is a bit out of date. For a native rsync, my options are, in order of performance are: 1. Use native asynchronous I/O. This would likely require a complete change for a large section of the code, and would require that the protocol state machine be completely described. The resulting code would probably be of most use to OpenVMS, but it could be adapted to threads. 2. Use pthreads. As I have limited experience with pthreads, I do not yet know the size of this task. The result though would be of benefit to all platforms if successful. 3. Use vfork() instead of fork(). An OpenVMS limitation is that the child process starts from the beginning and must initialize everything. 4. Use the OpenVMS LIB$SPAWN to start the receiving subprocess and link pipes to it. Most of the same difficulties as above, except that it is easier to use asynchronous I/O between the processes. All have challenges. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
rsync on Windows 2000?
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 many mirrors of the download directory. All I have checked are completely blank. I will confess that I have only been lightly browsing the mailing list traffic, so I may have missed something. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: SPAM on List...
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 regardless, these are long-term, global measures. Unfortunately it does look like long term measures, but I have two postmasters (unpaid volunteers) that can keep their domains very spamfree by two different methods of blocking list maintenance. Both were motivated mainly by bandwidth costs in their methods. But I can not second guess your duties and resources. What I care about is reducing admin load and spam transmission on samba.org right now. I understand. We both have our opinions on the matter. Our bogofilter setup seems to be doing *extremely well* at just that; I can see it catching many more messages and getting far fewer false positives before, and it is no longer necessary to clear queues by hand. I looked through the queue when I installed it and there were many posters who just happened e.g. to be from China and whose messages were basically dropped. Unless people have specific complaints about the new setup I intend to keep going along this path. I will agree that the SAMBA lists are being kept more spam free than some of the other mail servers that I get e-mail on. And while you are saying that you are not in favor of using blocking lists, you are blocking Korea by some method, but that could be just something that bogofilter has figured out. It is your servers and your decisions on how to allocate your resources. No spam blocking method is 100%. And I am not complaining about your efforts. I was just posting some methods of spam blocking in use, and of course my bias opinions on them. And as before, unless specifically addressed to on the subject, I do not intend to post further on this topic on this list. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: SPAM on List...
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 sender does not realize it. Filtering is also the most expensive and innefficient way to deal with spam, if you control the e-mail server. It is kinder to the senders (even though some may not appreciate it) to use one or more DNS based blocking lists to keep the spam down. That way the sender gets notified that there is a spam problem with the server or domain that they are sending from, and they can either put pressure on their ISP to fix it, or if it turns out that the ISP values the spammers money more than their other customers, they can find another ISP. Many e-mail servers are now using DNS based blocking list. They are blocking open-relays, open-proxies, Known Dialup ranges, and address blocks that have sent a high volume of spam. The SAMBA-TECHNICAL list reported that they have gone to the bl.spamcop.net blocking list, and it has been relatively spam free since then. The bl.spamcop.net is an aggressive blocking list with a quick trigger. And there are spamcop members on that list that send feeback to spamcop that if a spammer shows up, only one or two spams will show up from that source. It takes a few spam requests to trigger a block, and there is a penalty for false or malicious reports. Reports are only accepted from registered spamcop members. There is no charge for registering. Most of the blocking lists on the Internet take a long time for the sending I.P or block to get off. The spamcop blocking list entries expire in as short as 3 hours from the last reported spam. If the ISP shows up on spam reports chronically, it then can take up to one week for the last reported spam to get de-listed. This makes the bl.spamcop.net good for a mailing list. If the e-mail is bounced with the code for try-again, instead of permantently fatal, and the sender is on an ISP that responds to spam complaints, the e-mail would probably get posted that day. If the sender's ISP is not responding to spam complaints, it is likely that the sender is not having much luck getting anyone to accept their e-mail. QSL.NET also appears to use the spamcop blocking list. They are doing it because spam last year was costing them $30% of their internet costs. While most of you may pay a fixed rate for your e-mail, an ISP or a large company have to pay based on the amount of data transfered. With e-mail, a postmaster do not know how much the e-mail is going to cost until the server has accepted it. And the only thing that a mail server knows before accepting an e-mail is the sending server's I.P. address. A typical e-mail is under 5k bytes in size, some of the spam coming through is well over 50K bytes. So economically it is in the best interest of a postmaster to use blocking lists. It is up to the postmaster to determine how strict of ones to use. And many companies/postmasters do the blocking on a second level server, so the spam (and any thing that is mistaken for spam) is simply black holed. So bouncing a message because it comes from a server or I.P. block infested with a spammer may give someone a clue as to why they are not getting responses from their e-mail. Also many of the companies/ISPs that are blackholing spam will not admit to it because they do not want to be accused of censorship. So when someone complains to the ISP that an e-mail from a specific address not being received, they say that they can not find anything wrong and suggest that it be sent again. And magically things start working with that address, as long as the spam that caused it to be blocked in the first place does not start up again. The internet is dividing into ISPs and postmasters that tolerate spam and those that do not. And boycotting the ISPs that allow spam to be sent has been shown to be the only thing that is effective in reducing spam. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: superlifter design notes (was Re: ...
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. There are complications, though. Some time representations used by computer systems have ambiguities, two different times that are represented with the same number, or two different representations (created at different times) that actually end up representing the same time. There is potential loss of precision in converting timestamps. 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. A program that is replicating for backup purposes must not have any loss of data, including any operating specific file attributes. That is why I posted previously that they should be designed as two separate but related programs. Each application has unique requirements that needlessly complicates an application that does both. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: superlifter design notes (OpenVMS perspective)
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 right out of the box (think System Folder). Yes, rsync needs to not make assumptions about what's legal in a filename. Some OS's think slashes are path separators; some put them inside individual filenames. Some think [] are separators. We shouldn't try to make any assumptions. Agreed. For a file distribution program, for each file to be transferred, ideally the server will have a list of how the file should be represented on platforms that the server knows about. The client would be able to tell the server about new platforms, but the server would not be required to remember the information if it did not trust the client. As I work through my back log of e-mail messages, I will give some possible implemention details as answers to other posts. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: superlifter design notes (OpenVMS perspective)
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 code. I would much rather use them than try to reduce
the byte count by a complicated protocol.
Many compilers will inline ntohl() giving the call very low overhead.
5. Similarly, no silly tricks with forking, threads, or nonblocking
IO: one process, one IO.
Forking or multiple processes can be high cost on some platforms. I am
not experienced with Posix threads to judge their portability.
But as long as it is done right, non-blocking I/O is not a problem for me.
If you structure the protocol processing where no subroutine ever posts
a write and then waits for a read, you can set up a library that can be
used either blocking or non-blocking.
Yes, that's how librsync is structured.
Is it reasonable to assume that some kind of poll/select arrangement
is available everywhere? In other words, can I check to see if input
is available from a socket without needing to block trying to read
from it?
I can poll, but I prefer to cause the I/O completion to trigger a
completion routine. But that is not portable. :-)
I would hope that only a relatively small layer needs to know about
how and when IO is scheduled. It will make callbacks (or whatever) to
processes that produce and consume data. That layer can be adapted,
or if necessary, rewritten, to use whatever async IO features are
available on the relevant platform.
Test programs that internally fork() are very troublesome for me.
Starting a few hundred individually by a script are not.
If we always use fork/exec (aka spawn()) is that OK? Is it only
processes that fork and that then continue executing the same program
that cause trouble?
Mainly. I can deal with spawn() much easier than fork()
I can only read UNIX shell scripts of minor complexity.
Apparently Python runs on VMS. I'm in favour of using it for the test
suite; it's much more effective than sh.
Unfortunately the Python maintainer for VMS retired, and I have not been
able to figure out how to get his source to compile. I have got the
official Python to compile and link with only having to fix one severe
programming error. However it still is not running. I am isolating
where the problem is in my free time.
12. Try to keep the TCP pipe full in both directions at all times.
Pursuing this intently has worked well in rsync, but has also led to
a complicated design prone to deadlocks.
Deadlocks can be avoided.
Do you mean that in the technical sense of deadlock avoidance?
i.e. checking for a cycle of dependencies and failing? That sounds
undesirably complex.
No by not using a complex protocol, so that there are no deadlocks.
9 Model files as composed of a stream of bytes, plus an optional
table of key-value attributes. Some of these can be distinguished to
model ownership, ACLs, resource forks, etc.
Not portable. This will effectively either exclude all non-UNIX or make
it very difficult to port to them.
Non-UNIX is not completely fair; as far as I know MacOS, Amiga,
OS/2, Windows, BeOS, and QNX are {byte stream + attributes + forks}
too.
I realize there are platforms which are record-oriented, but I don't
have much experience on them. How would the rsync algorithm even
operate on such things?
Record files need to be transmitted on record boundaries, not arbitrary
boundaries. Also random access can not be used. The file segments need
to be transmitted in order.
For a UNIX text file, a record is a line of text deliminated by the
line-feed character.
[This is turned out to be a big problem in porting SAMBA. An NT client
transfers a large file by sending 64K, skipping 32K, sending some more
and then sending the 32K later. Samba does not do this, so the
resulting corruption of a record structured file did not show up in the
initial testing. I still have not found the ideal fix for SAMBA, but
implemented a workaround.]
Is it sufficient to model them as ascii+linefeeds internally, and then
do any necessary translation away from that model on IO?
Yes as long as no partial records are transmitted. Partial records can
be a problem. If I now the rest of the record is coming, then I can
wait for it, but if the rest of the record is going to be skipped, then
it takes more work.
BINARY files are no real problem. The binary is either meaningful on
the client or server or it is not. However file attributes may need to
be maintained. If the file attributes are maintained, it would be
possible for me to have a OpenVMS indexed file moved up to a UNIX
server, and then back to another OpenVMS system and be usuable.
Possibly it would be nice to have a way to stash attributes that
cannot be represented
Re: superlifter design notes (was Re: ...
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. A program that is replicating for backup purposes must not have any loss of data, including any operating specific file attributes. That is why I posted previously that they should be designed as two separate but related programs. I'm not sure that the application space for rsync really divides neatly into two parts like that. Can you expand a bit more on how you think they would be used? Well remember, I am on the outside looking in, and of course I could be missing things. :-) I did post this previously, but the message apparently got buried the large number of messages posted that day. The two uses for rsync that I am seeing discussed on this list are: Backup: A low overhead and possibly distance backup of disks or directory. In the case of a backup, usually it is the same platform, or one that is very close to being the same. Also it is important that security information, and file attributes all be properly maintained. The mapping of security information is platform specific, so this is a going to be an ongoing problem. It is also critical that timestamps be maintained. Since this is usually the same or closely similar platforms, a VFS layer can be used to store and retrieve attributes. No special attribute files or host based translations should be needed. The downsides are that as far as I can see there are no portable standard APIs to retrieve the security information, and as more variants are discovered, it may be hard to work them in for backward compatability. Because you are distributing an arbitrary set of directories, it is ususally not permitted to add files to assist in the transfer. This also seems to be an addition to rsync's original mission. Also using something like rsync for backup of binary files has the potential for undetected corruption. While the checksumming algorithm is good, it is not guaranteed to be perfect. And no, I do not want to recycle the old arguments about this. With a text file, the set of possible values is restricted enough that it is unlikely that the checksum method would fail, and if it did, the resulting corruption is more easily detected. File Distribution: A low overhead method of keeping local source directory trees synchronized with remote distributions. In this case, strict binary preservation of time stamps is not needed and maintaining security attributes is usually not desired. So that is two problems eliminated. What rsync does not do now, is differentiate between text files and binary files. A client that uses a different internal format for text files than binary files needs to do extra work. And unless the server tells it what type of file is coming, it must guess based on the filename. But you are specifically distributing a special tree of files in this case, not an arbitrary directory. That gives you the ability to add special attribute files to assist in the transfer. So while the two uses have a lot in common, there are significant differences, and having one program attempt to do both can lead to greater complexity. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: superlifter design notes (OpenVMS perspective)
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 allows optimization to be done by the compiler, and tight optimization should be driven by profiling tools. 4. Keep the socket open until the client gets bored. (Avoids startup time; good for on-line mirroring; good for interactive clients.) I am afraid I do not quite understand this one. Are you refering to a server waiting for a reconnect for a while instead of reconnecting? If so, that seems to be a standard behavior for network daemons. 5. Similarly, no silly tricks with forking, threads, or nonblocking IO: one process, one IO. Forking or multiple processes can be high cost on some platforms. I am not experienced with Posix threads to judge their portability. But as long as it is done right, non-blocking I/O is not a problem for me. If you structure the protocol processing where no subroutine ever posts a write and then waits for a read, you can set up a library that can be used either blocking or non-blocking. The same for file access. On OpenVMS, I can do all I/O in a non-blocking manor. The problem is that I must use native I/O calls to do so. If the structure is that after any I/O, control returns to a common point for the next step in the protocol, then it is easy to move from a blocking implementation to a non-blocking one. MACROs can probably be used to allow common code to be used for blocking or non-blocking implementations. Two systems that use non-blocking mode can push a higher data rate through the same time period. This is an area where I can offer help to produce a clean implementation. One of the obstacles to me cleanly implementing RSYNC as a single process is when a subroutine is waiting for a response to a command that it sent. If that subroutine is called from as an asynchronous event, it blocks all other execution in that process. That same practice hurts in SAMBA. 8. Design for testability. For example: don't rely on global resources that may not be available when testing; do make behaviours deterministic to ease testing. Test programs that internally fork() are very troublesome for me. Starting a few hundred individually by a script are not. I can only read UNIX shell scripts of minor complexity. 10. Have a design that is as simple as possible. 11. Smart clients, dumb servers. This is claimed to be a good design pattern for internet software. rsync at the moment does not really adhere to it. Part of the point of rsync is that having a smarter server can make things much more efficient. A strength of this approach is that to add features, you (often) only need to add them to the client. It should be a case of who can do the job easier. 12. Try to keep the TCP pipe full in both directions at all times. Pursuing this intently has worked well in rsync, but has also led to a complicated design prone to deadlocks. Deadlocks can be avoided. Make sure if an I/O is initiated, that the next step is to return to the protocol dispatching routine. General design ideas 9 Model files as composed of a stream of bytes, plus an optional table of key-value attributes. Some of these can be distinguished to model ownership, ACLs, resource forks, etc. Not portable. This will effectively either exclude all non-UNIX or make it very difficult to port to them. Binary files are a stream of bytes. Text files are a stream of records. Many systems do not store text files as a stream of bytes. They may or may not even be ASCII. If you are going to maintain meta files for ACLs and Resource Forks. Then there should be some provision to supply attributes for an entire directory or individual files. BINARY files are no real problem. The binary is either meaningful on the client or server or it is not. However file attributes may need to be maintained. If the file attributes are maintained, it would be possible for me to have a OpenVMS indexed file moved up to a UNIX server, and then back to another OpenVMS system and be usuable. Currently in order to do so, I must encapsulate them in a .ZIP archive. That is .ZIP, not GZIP or BZIP. On OpenVMS those are only useful to transfer source and a limited subset of binaries. TEXT files are much different than binary files, except on UNIX. A text file needs to be processed by records, and on many systems can not have the records updated randomly, or if they do it is not real efficient. If a target use for this program is to be for assisting in cross platform open source synchronization, then it really needs to properly address the text files. A server should know how to represent a TEXT file in a portable format to the client. Stream records in ASCII, delimited
Re: mixed case file systems.
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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Initial debug of client - Need command line help
[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 debugger can handle forked processes, but it can be tricky. The big problem with the one that I have is that I do not know how to switch the focus from one process to another while the session the debugger is focused on is running (not at a break point). I have temporarily put a special debugger break point in the source after the child process is started. If I did not do that, I could loose control of the parent process. It is easy to lose control of a multi-process debugging session. I am guessing that the initial fork() of RSH is to allow the user to initiate an rsync client session to run in the background with out tying up the main shell session. I am just starting to learn the logic flow and command line arguments for rsync. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Initial debug of client - Need command line help
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 from a second shell session. On the client side, I am having trouble finding the right options so that it will connect up to the local server with out fork() a copy of itself or trying to exec the rsh command. It should more or less create a copy with the same options, except that --server will always be set, and --sender will be inverted. See server_options() It would be much better debugging if I could avoid the fork() attempt to exec the RSH shell for the local connection. The other complication is that on OpenVMS, RSH is a registered program to the shell. An system(RSH) will succeed, an exec(RSH) will fail. I can work around that, but it seems like having it in there for debugging needlessly complicates things. OpenVMS does not have a fork() function. It can create a child process, but all the I/O and memory must be set up from scratch. Passing I/O from an RSH subprocess through an extra debugger session can be a bit hassle. I would rather concentrate on making sure that the receiver child process is initialized properly. So are you saying for the client I should try: rsync --server --sender --port=9000 localhost:ftp where ftp is the entry in the servers rsyncd.conf file? The server process is running on --port=9000 for the purposes of testing. Does this mean that the client needs an rsyncd.conf file also? Sorry if I am a little dense on this. I looked at trying to convert the receiver process to an AST, but that requires that none of the inner level subroutines ever wait for an I/O to complete. I would have to do a complete rewrite based on the protocol that is going over the wire. And I do not see a description of that protocol in the distribution. -John [EMAIL PROTECTED] Personal Opinion Only -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsynd-2.5.1 / checksum.c patches
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 efficiency.
There may be more cases in this module where type (char) is being used
instead of what appears should be (unsigned char).
-John
[EMAIL PROTECTED]
Personal Opinion Only
EAGLE type checksum.gdiff
--- ref_src:checksum.c Sat Jan 5 13:27:01 2002
+++ lcl_src:checksum.c Sun Jan 6 22:41:06 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND PRJ_SRC:CHECKSUM.TPU on
6-JAN-2002 22:41:06.45 OPENVMS_AXP */
/*
Copyright (C) Andrew Tridgell 1996
Copyright (C) Paul Mackerras 1996
@@ -30,7 +31,7 @@
a simple 32 bit checksum that can be upadted from either end
(inspired by Mark Adler's Adler-32 checksum)
*/
-uint32 get_checksum1(char *buf1,int len)
+uint32 get_checksum1(const void *buf1,int len)
{
int i;
uint32 s1, s2;
@@ -49,7 +50,7 @@
}
-void get_checksum2(char *buf,int len,char *sum)
+void get_checksum2(const void *buf,int len,unsigned char *sum)
{
int i;
static char *buf1;
@@ -82,7 +83,7 @@
}
-void file_checksum(char *fname,char *sum,OFF_T size)
+void file_checksum(const char *fname, void *sum,OFF_T size)
{
OFF_T i;
struct map_struct *buf;
@@ -133,15 +134,17 @@
void sum_init(void)
{
- char s[4];
+ unsigned char s[4];
mdfour_begin(md);
sumresidue=0;
SIVAL(s,0,checksum_seed);
sum_update(s,4);
}
-void sum_update(char *p,int len)
+void sum_update(void *p1,int len)
{
+unsigned char * p;
+ p = (unsigned char *)p1;
int i;
if (len + sumresidue CSUM_CHUNK) {
memcpy(sumrbuf+sumresidue, p, len);
@@ -170,7 +173,7 @@
}
}
-void sum_end(char *sum)
+void sum_end(void *sum)
{
if (sumresidue) {
mdfour_update(md, (uchar *)sumrbuf, sumresidue);
rsynd-2.5.1 / authenticate.c patch
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.
-John
[EMAIL PROTECTED]
Personal Opinion Only
EAGLE type authenticate.gdiff
--- ref_src:authenticate.c Sat Jan 5 13:27:01 2002
+++ lcl_src:authenticate.c Sat Jan 12 21:58:20 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND
PRJ_SRC:AUTHENTICATE.TPU on 12-JAN-2002 21:58:20.16 OPENVMS_AXP */
/* -*- c-file-style: linux; -*-
Copyright (C) 1998-2000 by Andrew Tridgell
@@ -24,7 +25,7 @@
encode a buffer using base64 - simple and slow algorithm. null
terminates the result.
***/
-static void base64_encode(char *buf, int len, char *out)
+static void base64_encode(const void *buf, int len, char *out)
{
char *b64 =
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456
789+/;
int bit_offset, byte_offset, idx, i;
@@ -49,7 +50,7 @@
}
/* create a 16 byte challenge buffer */
-static void gen_challenge(char *addr, char *challenge)
+static void gen_challenge(const char *addr, void *challenge)
{
char input[32];
struct timeval tv;
rsync-2.5.1 / popt patches
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
Compiler: Compaq C T6.5
Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE)
SYSTEM.H is doing tests on undefined macros, and if the target is not
_GNUC__ or _AIX is assuming that a specific prototype exists.
This patch prototypes the alloca() function to be more consistent, but
since any platform that supports the alloca() function should be able to
provide a prototype, a specific prototype probably should not ever be
needed. More work is probably needed with the alloca definiton.
POPT.C was assuming that the presence of an alloca() function was based
on the existance of HAVE_ALLOCA_H. The macro HAVE_ALLOCA_H should only
be indicating the presence of a header file.
The presence of an ALLOCA function should be based on the macro
HAVE_ALLOCA. This of course will require a change to the CONFIGURE
scripts, which I can not test.
POPT.C also contained a conditional expression testing if the unsigned
variable argx is greater than 0. Since this value can never be less
than 0, a more appropriate test is to check if the value is non-zero.
[Lint type diagnostic]
POPT.H, POPT.C have an error with the definition of the poptStrerror
routine.
POPTHELP.C has an error with the definitions of the
getTableTranslationDomain() and getArgDescrip() routines.
Having a const qualifier on function return value is not legal.
It is legal to return a const pointer.
EAGLE type lcl_popt:system_h.gdiff
--- ref_popt:system.h Fri Feb 23 19:32:22 2001
+++ lcl_popt:system.h Sun Jan 6 08:42:28 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_popt:system.tpu on
6-JAN-2002 08:42:28.07 OPENVMS_AXP */
#ifdef HAVE_CONFIG_H
#include config.h
#endif
@@ -7,7 +8,7 @@
#include fcntl.h
#include limits.h
-#if HAVE_MCHECK_H
+#ifdef HAVE_MCHECK_H
#include mcheck.h
#endif
@@ -15,7 +16,7 @@
#include stdlib.h
#include string.h
-#if HAVE_UNISTD_H
+#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
@@ -27,14 +28,14 @@
/* AIX requires this to be the first thing in the file. */
#ifndef __GNUC__
-# if HAVE_ALLOCA_H
+#ifdef HAVE_ALLOCA_H
# include alloca.h
# else
# ifdef _AIX
#pragma alloca
# else
# ifndef alloca /* predefined by HP cc +Olibcalls */
-char *alloca ();
+void * alloca(unsigned int x);
# endif
# endif
# endif
@@ -44,7 +45,7 @@
/*@only@*/ char * xstrdup (const char *str);
-#if HAVE_MCHECK_H defined(__GNUC__)
+#if defined(HAVE_MCHECK_H) defined(__GNUC__)
#definevmefail() (fprintf(stderr, virtual memory
exhausted.\n),
exit(EXIT_FAILURE), NULL)
#define xstrdup(_str) (strcpy((malloc(strlen(_str)+1) ? :
vmefail()), (_str))
)
#else
EAGLE type lcl_popt:popt_h.gdiff
--- ref_popt:popt.h Fri Feb 23 19:32:22 2001
+++ lcl_popt:popt.h Sun Jan 6 08:42:28 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_popt:popt.tpu on
6-JAN-2002 08:42:28.57 OPENVMS_AXP */
/* (C) 1998 Red Hat Software, Inc. -- Licensing details are in the COPYING
file accompanying popt source distributions, available from
ftp://ftp.redhat.com/pub/code/popt */
@@ -114,7 +115,7 @@
/*@out@*/ int * argcPtr, /*@out@*/ const char *** argvPtr);
int poptParseArgvString(const char * s,
/*@out@*/ int * argcPtr, /*@out@*/ const char *** argvPtr);
-/*@observer@*/ const char *const poptStrerror(const int error);
+/*@observer@*/ const char * poptStrerror(const int error);
void poptSetExecPath(poptContext con, const char * path, int
allowAbsolute);
void poptPrintHelp(poptContext con, FILE * f, int flags);
void poptPrintUsage(poptContext con, FILE * f, int flags);
EAGLE type lcl_popt:popthelp.gdiff
--- ref_popt:popthelp.c Fri Feb 23 19:32:22 2001
+++ lcl_popt:popthelp.c Sun Jan 6 08:42:42 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_popt:popthelp.tpu
on 6-JAN-2002 08:42:42.26 OPENVMS_AXP */
/* -*- Mode: C; tab-width: 8; indent-tabs-mode: t; c-basic-offset: 4
-*- */
/* (C) 1998 Red Hat Software, Inc. -- Licensing details are in the COPYING
@@ -26,7 +27,7 @@
} ;
-/*@observer@*/ /*@null@*/ static const char *const
+/*@observer@*/ /*@null@*/ static const char *
getTableTranslationDomain(const struct poptOption *table)
{
const struct poptOption *opt;
@@ -41,7 +42,7 @@
return NULL;
}
-/*@observer@*/ /*@null@*/ static const char *const
+/*@observer@*/ /*@null@*/ static const char *
getArgDescrip(const struct poptOption * opt, const char
*translation_domain)
{
if (!(opt-argInfo POPT_ARG_MASK)) return NULL;
EAGLE type lcl_popt:popt.gdiff
--- ref_popt:popt.c Thu Mar 22 21:44:50 2001
+++ lcl_popt:popt.c Sun Jan 6 08:42:33
rsync-2.5.1 / lib patches
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 OpenVMS can not deal with relative
path names in #include files.
Also the local prototype for getenv() does not match the one in stdlib.h.
-John
[EMAIL PROTECTED]
Personal Opinion Only
PROJECT_ROOT:[rsync_vms.LIB]FNMATCH.GDIFF;1
--- ref_lib:fnmatch.c Sat Jan 29 05:35:04 2000
+++ lcl_lib:fnmatch.c Sun Jan 6 08:42:06 2002
@@ -1,4 +1,9 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_lib:fnmatch.tpu on
6-JAN-2
002 08:42:06.02 OPENVMS_AXP */
+#ifdef __VMS
+#include rsync.h
+#else
#include ../rsync.h
+#endif
#ifndef HAVE_FNMATCH
/* - THE FOLLOWING UP TO 'END' is glibc-2.1.2 posix/fnmatch.c
@@ -128,7 +133,11 @@
whose names are inconsistent. */
# if !defined _LIBC !defined getenv
+#ifdef __VMS
+/* defined in stdlib.h */
+#else
extern char *getenv ();
+#endif
# endif
# ifndef errno
PROJECT_ROOT:[rsync_vms.LIB]MDFOUR.GDIFF;1
--- ref_lib:mdfour.cThu Nov 29 18:21:10 2001
+++ lcl_lib:mdfour.cSun Jan 6 08:42:14 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu on 6-JAN-2002 08:42:14.63
OPENVMS_
AXP */
/*
Unix SMB/Netbios implementation.
Version 1.9.
@@ -209,7 +210,11 @@
}
#if 0
+#ifdef __VMS
+#include md4.h
+#else
#include ../md4.h
+#endif
static void file_checksum2(char *fname)
{
rsync-2.5.1 / tls.c, backup.c, syscall.c not honoring config.h SUPPORT_LINKS setting
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 PROTECTED]
Personal Opinion Only
EAGLE type backup.gdiff
--- ref_src:backup.cSat Jan 5 13:27:01 2002
+++ lcl_src:backup.cSun Jan 6 08:39:05 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_src:backup.tpu on
6-JAN-2002 08:39:05.23 OPENVMS_AXP */
/*
Copyright (C) Andrew Tridgell 1999
@@ -19,6 +20,9 @@
/* backup handling code */
#include rsync.h
+#if SUPPORT_LINKS 1
+#define do_lstat do_stat
+#endif
extern int verbose;
extern char *backup_suffix;
EAGLE type syscall.gdiff
--- ref_src:syscall.c Sat Jan 5 13:27:07 2002
+++ lcl_src:syscall.c Sun Jan 6 08:40:58 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_src:syscall.tpu on
6-JAN-2002 08:40:58.14 OPENVMS_AXP */
/*
Copyright (C) Andrew Tridgell 1998
@@ -35,14 +36,16 @@
return unlink(fname);
}
+#if SUPPORT_LINKS
int do_symlink(char *fname1, char *fname2)
{
if (dry_run) return 0;
CHECK_RO
return symlink(fname1, fname2);
}
+#endif
-#if HAVE_LINK
+#if SUPPORT_HARD_LINKS
int do_link(char *fname1, char *fname2)
{
if (dry_run) return 0;
@@ -58,7 +61,7 @@
return lchown(path, owner, group);
}
-#if HAVE_MKNOD
+#ifdef HAVE_MKNOD
int do_mknod(char *pathname, mode_t mode, dev_t dev)
{
if (dry_run) return 0;
@@ -90,7 +93,7 @@
return open(pathname, flags, mode);
}
-#if HAVE_CHMOD
+#ifdef HAVE_CHMOD
int do_chmod(const char *path, mode_t mode)
{
if (dry_run) return 0;
@@ -138,7 +141,7 @@
int do_stat(const char *fname, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return stat64(fname, st);
#else
return stat(fname, st);
@@ -148,7 +151,7 @@
#if SUPPORT_LINKS
int do_lstat(const char *fname, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return lstat64(fname, st);
#else
return lstat(fname, st);
@@ -158,7 +161,7 @@
int do_fstat(int fd, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return fstat64(fd, st);
#else
return fstat(fd, st);
@@ -167,7 +170,7 @@
OFF_T do_lseek(int fd, OFF_T offset, int whence)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
off64_t lseek64();
return lseek64(fd, offset, whence);
#else
@@ -178,7 +181,7 @@
#ifdef USE_MMAP
void *do_mmap(void *start, int len, int prot, int flags, int fd, OFF_T
offset)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return mmap64(start, len, prot, flags, fd, offset);
#else
return mmap(start, len, prot, flags, fd, offset);
@@ -188,7 +191,7 @@
char *d_name(struct dirent *di)
{
-#if HAVE_BROKEN_READDIR
+#ifdef HAVE_BROKEN_READDIR
return (di-d_name - 2);
#else
return di-d_name;
EAGLE type tls.gdiff
--- ref_src:tls.c Sat Jan 5 13:27:07 2002
+++ lcl_src:tls.c Sun Jan 6 15:27:51 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_src:tls.tpu on
6-JAN-2002 15:27:51.55 OPENVMS_AXP */
/* -*- c-file-style: linux -*-
*
* Copyright (C) 2001 by Martin Pool [EMAIL PROTECTED]
@@ -68,7 +69,11 @@
char datebuf[50];
char linkbuf[4096];
+#if SUPPORT_LINKS
if (do_lstat(fname, buf) == -1)
+#else
+ if (do_stat(fname, buf) == -1)
+#endif
failed (stat, fname);
/* The size of anything but a regular file is probably not
@@ -86,7 +91,11 @@
buf.st_uid = buf.st_gid = 0;
strcpy(linkbuf, - );
/* const-cast required for silly UNICOS headers */
+#if SUPPORT_LINKS
len = readlink((char *) fname, linkbuf+4,
sizeof(linkbuf) - 4);
+#else
+ len = -1;
+#endif
if (len == -1)
failed(readlink, fname);
else
rsync-2.5.1 / updated syscall.c const patch
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 the conflicts between
signed and unsigned values.
-John
[EMAIL PROTECTED]
Personal Opinion Only
EAGLE type syscall.gdiff
--- ref_src:syscall.c Sat Jan 5 13:27:07 2002
+++ lcl_src:syscall.c Sun Jan 6 23:12:41 2002
@@ -1,3 +1,4 @@
+/* Converted by prj_src:unix_c_to_vms_c.tpu AND prj_src:syscall.tpu on
6-JAN-2
002 23:12:41.17 OPENVMS_AXP */
/*
Copyright (C) Andrew Tridgell 1998
@@ -28,22 +29,24 @@
#define CHECK_RO if (read_only || list_only) {errno = EROFS; return -1;}
-int do_unlink(char *fname)
+int do_unlink(const char *fname)
{
if (dry_run) return 0;
CHECK_RO
return unlink(fname);
}
-int do_symlink(char *fname1, char *fname2)
+#if SUPPORT_LINKS
+int do_symlink(const char *fname1, const char *fname2)
{
if (dry_run) return 0;
CHECK_RO
return symlink(fname1, fname2);
}
+#endif
-#if HAVE_LINK
-int do_link(char *fname1, char *fname2)
+#if SUPPORT_HARD_LINKS
+int do_link(const char *fname1, const char *fname2)
{
if (dry_run) return 0;
CHECK_RO
@@ -58,8 +61,8 @@
return lchown(path, owner, group);
}
-#if HAVE_MKNOD
-int do_mknod(char *pathname, mode_t mode, dev_t dev)
+#ifdef HAVE_MKNOD
+int do_mknod(const char *pathname, mode_t mode, dev_t dev)
{
if (dry_run) return 0;
CHECK_RO
@@ -67,14 +70,14 @@
}
#endif
-int do_rmdir(char *pathname)
+int do_rmdir(const char *pathname)
{
if (dry_run) return 0;
CHECK_RO
return rmdir(pathname);
}
-int do_open(char *pathname, int flags, mode_t mode)
+int do_open(const char * pathname, int flags, mode_t mode)
{
if (flags != O_RDONLY) {
if (dry_run) return -1;
@@ -90,7 +93,7 @@
return open(pathname, flags, mode);
}
-#if HAVE_CHMOD
+#ifdef HAVE_CHMOD
int do_chmod(const char *path, mode_t mode)
{
if (dry_run) return 0;
@@ -99,14 +102,14 @@
}
#endif
-int do_rename(char *fname1, char *fname2)
+int do_rename(const char *fname1, const char *fname2)
{
if (dry_run) return 0;
CHECK_RO
return rename(fname1, fname2);
}
-int do_mkdir(char *fname, mode_t mode)
+int do_mkdir(const char *fname, mode_t mode)
{
if (dry_run) return 0;
CHECK_RO
@@ -138,7 +141,7 @@
int do_stat(const char *fname, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return stat64(fname, st);
#else
return stat(fname, st);
@@ -148,7 +151,7 @@
#if SUPPORT_LINKS
int do_lstat(const char *fname, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return lstat64(fname, st);
#else
return lstat(fname, st);
@@ -158,7 +161,7 @@
int do_fstat(int fd, STRUCT_STAT *st)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return fstat64(fd, st);
#else
return fstat(fd, st);
@@ -167,7 +170,7 @@
OFF_T do_lseek(int fd, OFF_T offset, int whence)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
off64_t lseek64();
return lseek64(fd, offset, whence);
#else
@@ -178,7 +181,7 @@
#ifdef USE_MMAP
void *do_mmap(void *start, int len, int prot, int flags, int fd, OFF_T
offset)
{
-#if HAVE_OFF64_T
+#ifdef HAVE_OFF64_T
return mmap64(start, len, prot, flags, fd, offset);
#else
return mmap(start, len, prot, flags, fd, offset);
@@ -188,7 +191,7 @@
char *d_name(struct dirent *di)
{
-#if HAVE_BROKEN_READDIR
+#ifdef HAVE_BROKEN_READDIR
return (di-d_name - 2);
#else
return di-d_name;
Re: 2.5.1pre3 - Bugs in configure script / config.h.in breaks build.
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 be: #undef HAVE_SOCKLEN_T And then somewhere else, where the defintion is used, or in rsync.h #ifndef HAVE_SOCKLEN_T typedef socklen_t size_t #endif That's not enough because it needs to figure out what value to use to define socklen_t; the current logic in aclocal.m4 tries int size_t unsigned long unsigned long until it gets one to compile. Depending on the compile options selected or defaulted, and if standard headers are selected or not, a C compiler may not produce the expected results from one of the test programs in a configure script. One of the main reasons that the configure scripts do not work well off of a UNIX platform is that some UNIX library functions have multiple implementations for mapping to native operating system features. There are a number of cases where a programmer needs to select at compile time which behavior is correct. Or if the compiler is to conform to new standard or library routine behavior change or to be backwards compatable. So even if I were to obtain a UNIX compatable shell for OpenVMS like GNV, the configure results would likely still be misleading. For an autoconfigure to be truly cross platform, it must be table driven, so that a family of similar Operating systems like the *NIX could share common scripts, but non-*NIX operating systems can supply scripts that are specific to them. --- After this I ran into the ALLOCA mess. :-( With Compaq C, the ALLOCA function is __ALLOCA(X), and the prototype is: void * __ALLOCA(size_t x); But I do not have an alloca.h header file. So I had to rework both SYSTEM.H and POPT.C to get things to compile, as it was assuming the absence of alloca.h implied no alloca function, and if the compiler was not GCC and not on AIX, that there was a specific prototype for the alloca() function. So it appears that POPT.C needs to use #ifdef HAVE_ALLOCA instead of #ifdef HAVE_ALLOCA_H, which of course needs something to properly set it. I do not know what the correct fix for SYSTEM.H, I am not sure that a prototype should even be needed for a built in function. I can do debugging or testing of the configure scripts. So someone with a UNIX platform will need to verify what the fixes to the configure scripts need to be. OpenVMS does not execute configure scripts. They are harder to port than the applications, and tend to generate incorrect results for the OpenVMS platform even after they are ported. Instead, an OpenVMS DCL procedure is used to read the CONFIG.H.IN file and uses it to search the system libraries to see what routines and header definitions are present. Is there some other syntax that the procedure accepts to allow passing a value through? The procedure is basically looks for symbols in the libraries. Sort of like using grep to look things up in the header files instead of doing the test files. If it does not get a match from reading the config.h.in file, it then scans the configure. file to see if there is a simple assignment in it like: symbol = n If so, it then does a #define symbol n The DCL procedure has some special cases coded into it. I can place an additional one for socklen_t, now that I know about it. But it is still better to use the HAVE_SOCKLEN_T indicate if a substitution is needed. Basically I will put in a special case that if it sees #undef HAVE_SOCKLEN_T, and it does not find it in the standard header files, it will insert a #define HAVE_SOCKLEN_T 1 and then the needed typedef for socklen_t. The procedure is not perfect, but it is can handle building most of the config.h file. As a last step, the generate config.h file has a #include config_vms.h to load in a hand edited file that does the fine tuning. I am now getting an almost clean compile, but I had to fix a lot of char * definitions that either should have been unsigned char * or void * in order for the build to complete. I am still getting several diagnostics where the compiler is concerned about being asked to put negative constants into unsigned variables. Before I can start testing, I have to deal with the issue of OpenVMS not currently having a fork() function. I think that I can move one of the processes to run as a AST thread, which has much less overhead than the current implementation. I do not yet know how much code I will have to change to get that to work. -John [EMAIL PROTECTED] Personal Opinion Only
