RE: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
Ville Herva [mailto:[EMAIL PROTECTED]] wrote: Of course, whether O_TEXT is defined or not does not necessarily imply the availability of t, but I can't think of better alternative. Stratus VOS implements O_TEXT and O_BINARY but does not recognize t. We have the options defined in ANS C and in POSIX. I'm at home and don't have my reference materials handy, but I think this is going to be a problem for us. I can see looking at the code that we will reject the open if we see unknown letters. Please write a configure test. Even if we are wrong and we should be ignoring it, I have hundreds of machines in the field and it will be years before they are upgraded. The string concatenation thing is not an issue here. Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus -- 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: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
On Sun, Jan 26, 2003 at 09:43:06AM -0500, Green, Paul wrote:
Ville Herva [mailto:[EMAIL PROTECTED]] wrote:
Of course, whether O_TEXT is defined or not does not
necessarily imply the availability of t, but I
can't think of better alternative.
Stratus VOS implements O_TEXT and O_BINARY but does not recognize t. We
have the options defined in ANS C and in POSIX. I'm at home and don't have
my reference materials handy, but I think this is going to be a problem for
us. I can see looking at the code that we will reject the open if we see
unknown letters.
Please write a configure test. Even if we are wrong and we should be
ignoring it, I have hundreds of machines in the field and it will be years
before they are upgraded.
The string concatenation thing is not an issue here.
On the systems where O_TEXT and rt have meaning are we
looking at anything other than converting \r\n to \n?
If not i don't think we need the O_TEXT stuff.
I did a quick survey of where you have the O_TEXT and O_TEXT_STR
and of the one other calls to fopen (logfile).
authenticate.c: fd = open(fname,O_RDONLY | O_TEXT);
get_secret() already discards \r
authenticate.c: if ( (fd=open(filename,O_RDONLY | O_TEXT)) == -1) {
getpassf() treats \r the same as \n
clientserver.c: FILE *f = fopen(motd,r O_TEXT_STR);
simply passes contents of motd file unchanged to client
does it matter if there are \r chars in the file?
exclude.c: f = fopen(fname,r O_TEXT_STR);
exclude.c: f = fdopen(0, r O_TEXT_STR);
the file is processed with
while (fgets(line,MAXPATHLEN,f)) {
int l = strlen(line);
if (l line[l-1] == '\n') l--;
line[l] = 0;
if we add
if (l line[l-1] == '\r') l--;
after the \n processing that will handle the \r\n case
or we can replace the \n line with
while (l (line[l-1] == '\n'|| line[l-1] == '\r')) l--;
and this function will be covered.
params.c: OpenedFile = fopen( FileName, r O_TEXT_STR );
since \r is a whitespace character it should be
ignored.
Based on this i don't think we need to worry about O_TEXT or
rt mode. The only place i can imagine we might want text
mode is the log file and i imagine that admins can cope with
EOL issues.
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
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: opendir(somedir/somefile): Not enough space -- why?
Even though it was a pain in the *ss, I broke up the transfer into several chunks (logically organized by sub-directories of the source) and wrote a script to batch the job. It worked, better and faster than via NFS. Mounting the source directory via NFS is not a solution that makes one feel good - it ended up with errors. _ Bill On Fri, 24 Jan 2003 11:54:13 -0700 Bill Geddes [EMAIL PROTECTED] wrote: I am attempting to use rsync to copy a large filesystem from an HP-UX server to a Linux server with more than enough filespace. This operation fails. A small directory from the same HP-UX server can be transfered just as expected. The HP-UX server is the source. It has 1Gb RAM - the output of bdf for the volume the source files is on is: Filesystem kbytesused avail %used Mounted on /dev/vg02/apps 6144 52722896 8652256 86% /apps On the target Linux server, I have 1Gb RAM and 1TB of free space: Filesystem 1k-blocks Used Available Use% Mounted on /dev/tcvg1/tcvol11007898916 33408 956667148 1% /vol1 I have apps configured properly as a service in the rsyncd.conf file. I started rsync in daemon mode on the HP-UX server, and from the Linux server I invoked: rsync --numeric-ids -vvva root@hpuxsrv::apps /vol1/asic_apps/ The file list get transferred, but then I just get repeated lines of errors: recv_file_name(some_dir/fm_v200209) opendir(some_dir/fm_v200209): Not enough space I have tried with --blocking-io and --no-blocking-io, with --bwlimitXXX. Same problem each time. Any insight is appreciated. -- Bill Geddes [EMAIL PROTECTED] -- UNIX is user friendly, it's just picky about who its friends are. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- Bill Geddes [EMAIL PROTECTED] -- UNIX is user friendly, it's just picky about who its friends are. -- 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: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
On Sun, Jan 26, 2003 at 08:16:50AM -0800, jw schultz wrote:
authenticate.c: fd = open(fname,O_RDONLY | O_TEXT);
get_secret() already discards \r
authenticate.c: if ( (fd=open(filename,O_RDONLY | O_TEXT)) == -1) {
getpassf() treats \r the same as \n
Yeah, these already handle both Mac and PC line endings, so I removed
the O_TEXT bit from these.
clientserver.c: FILE *f = fopen(motd,r O_TEXT_STR);
simply passes contents of motd file unchanged to client
does it matter if there are \r chars in the file?
I'm trying to imagine what will happen for Mac systems as well. Since
the default for files is to open them in text mode on a Mac (and they
don't have the Cygwin weirdness of trying to override a binary-mode
mount, right?), then I think you're right here -- the extra \r that
might come from a PC system should hopefully cause no problems (but we
should test this). In the meantime, I think it would be safe to revert
this change.
exclude.c: f = fopen(fname,r O_TEXT_STR);
exclude.c: f = fdopen(0, r O_TEXT_STR);
the file is processed with
while (fgets(line,MAXPATHLEN,f)) {
int l = strlen(line);
if (l line[l-1] == '\n') l--;
line[l] = 0;
if we add
if (l line[l-1] == '\r') l--;
after the \n processing that will handle the \r\n case
or we can replace the \n line with
while (l (line[l-1] == '\n'|| line[l-1] == '\r')) l--;
and this function will be covered.
As long as Mac systems are reading the file in text mode without the
O_TEXT_STR, we should be fine (and I believe that to be the case).
params.c: OpenedFile = fopen( FileName, r O_TEXT_STR );
since \r is a whitespace character it should be
ignored.
Sounds right (though I haven't verified your analysis).
Since it sounds like the t has a potential for problems, I'm taking
these recent changes out and will just put in the one suggested change
to ignore a '\r' at the end of the line. This should be safer for the
current release.
..wayne..
--
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: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
Dave Dykstra wrote:
Alright. Max, could you quickly verify if the latest CVS version
works OK for you on Cygwin?
What, in particular? I'm not a very good testcase, because I use binary
mounts and unix line endings everywhere.
It compiles and does syncs with remote rsync daemons, which is my normal
usage.
Max.
It's better to always handle all three styles of line terminations
anyway, because there are other situations than systems that have
O_TEXT defined where it might be wanted, for example a Linux system
that has a Windows filesystem mounted.
- Dave
On Sun, Jan 26, 2003 at 12:07:07PM -0800, Wayne Davison wrote:
On Sun, Jan 26, 2003 at 08:16:50AM -0800, jw schultz wrote:
authenticate.c: fd = open(fname,O_RDONLY | O_TEXT);
get_secret() already discards \r
authenticate.c: if ( (fd=open(filename,O_RDONLY | O_TEXT)) == -1) {
getpassf() treats \r the same as \n
Yeah, these already handle both Mac and PC line endings, so I removed
the O_TEXT bit from these.
clientserver.c: FILE *f = fopen(motd,r O_TEXT_STR);
simply passes contents of motd file unchanged to client
does it matter if there are \r chars in the file?
I'm trying to imagine what will happen for Mac systems as well.
Since the default for files is to open them in text mode on a Mac
(and they don't have the Cygwin weirdness of trying to override a
binary-mode mount, right?), then I think you're right here -- the
extra \r that might come from a PC system should hopefully cause no
problems (but we should test this). In the meantime, I think it
would be safe to revert this change.
exclude.c: f = fopen(fname,r O_TEXT_STR);
exclude.c: f = fdopen(0, r O_TEXT_STR);
the file is processed with
while (fgets(line,MAXPATHLEN,f)) {
int l = strlen(line);
if (l line[l-1] == '\n') l--;
line[l] = 0;
if we add
if (l line[l-1] == '\r') l--;
after the \n processing that will handle the \r\n case
or we can replace the \n line with
while (l (line[l-1] == '\n'|| line[l-1] == '\r')) l--;
and this function will be covered.
As long as Mac systems are reading the file in text mode without the
O_TEXT_STR, we should be fine (and I believe that to be the case).
params.c: OpenedFile = fopen( FileName, r O_TEXT_STR );
since \r is a whitespace character it should be
ignored.
Sounds right (though I haven't verified your analysis).
Since it sounds like the t has a potential for problems, I'm taking
these recent changes out and will just put in the one suggested
change to ignore a '\r' at the end of the line. This should be
safer for the current release.
...wayne..
--
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: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote: Dave Dykstra wrote: Alright. Max, could you quickly verify if the latest CVS version works OK for you on Cygwin? What, in particular? I'm not a very good testcase, because I use binary mounts and unix line endings everywhere. It compiles and does syncs with remote rsync daemons, which is my normal usage. Max. See if exclude files with DOS line endings work ok for you, and also the other config files if you can. - Dave -- 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: Storage compression patch for Rsync (unfinished)
Is there any reason why caching programs would need to set the
value, rather than it just being a fixed value? I think it is hard
to describe what this is for and what it should be set to. Maybe a
--fixed-checksum-seed option would make some sense, or for a caching
mechanism to be built in to rsync if it is shown to be very valuable.
I don't think I'll include the option in 2.5.6. I know people have
proposed some caching mechanisms in the past and they've been rejected
for one reason or another.
- Dave
On Fri, Jan 17, 2003 at 11:19:35PM -0800, Craig Barratt wrote:
While the idea of rsyncing with compression is mildly
attractive i can't say i care for the new compression
format. It would be better just to use the standard gzip or
other format. If you are going to create a new file type
you could at least discuss storing the blocksums in it so
that the receiver wouldn't have to generate them.
Yes! Caching the block checksums and file checksums could yield a large
improvement for the receiver. However, an integer checksum seed is used
in each block and file MD4 checksum. The default value is unix time() on
the server, sent to the client at startup.
So currently you can't cache block and file checksums (technically it is
possible for block checksums since the checksum seed is appended at the
end of each block, so you could cache the MD4 state prior to the checksum
seed being added; for files you can't since the checksum seed is at the
start).
Enter a new option, --checksum-seed=NUM, that allows the checksum seed to
be fixed. I've attached a patch below against 2.5.6pre1.
The motivation for this is that BackupPC (http://backuppc.sourceforge.net)
will shortly release rsync support, and I plan to support caching
block and file checksums (in addition to the existing compression,
hardlinking among any identical files etc). So it would be really
great if this patch, or something similar, could make it into 2.5.6
or at a minimum the contributed patch area in 2.5.6.
[Also, this option is convenient for debugging because it makes the
rsync traffic identical between runs, assuming the file states at
each end are the same too.]
Thanks,
Craig
###
diff -bur rsync-2.5.6pre1/checksum.c rsync-2.5.6pre1-csum/checksum.c
--- rsync-2.5.6pre1/checksum.cMon Apr 8 01:31:57 2002
+++ rsync-2.5.6pre1-csum/checksum.c Thu Jan 16 23:38:47 2003
@@ -23,7 +23,7 @@
#define CSUM_CHUNK 64
-int checksum_seed = 0;
+extern int checksum_seed;
extern int remote_version;
/*
diff -bur rsync-2.5.6pre1/compat.c rsync-2.5.6pre1-csum/compat.c
--- rsync-2.5.6pre1/compat.c Sun Apr 7 20:50:13 2002
+++ rsync-2.5.6pre1-csum/compat.c Fri Jan 17 21:18:35 2003
@@ -35,7 +35,7 @@
extern int preserve_times;
extern int always_checksum;
extern int checksum_seed;
-
+extern int checksum_seed_set;
extern int remote_version;
extern int verbose;
@@ -64,11 +64,14 @@
if (remote_version = 12) {
if (am_server) {
- if (read_batch || write_batch) /* dw */
+ if (read_batch || write_batch) { /* dw */
+ if ( !checksum_seed_set )
checksum_seed = 32761;
- else
+ } else {
+ if ( !checksum_seed_set )
checksum_seed = time(NULL);
write_int(f_out,checksum_seed);
+ }
} else {
checksum_seed = read_int(f_in);
}
diff -bur rsync-2.5.6pre1/options.c rsync-2.5.6pre1-csum/options.c
--- rsync-2.5.6pre1/options.c Fri Jan 10 17:30:11 2003
+++ rsync-2.5.6pre1-csum/options.cThu Jan 16 23:39:17 2003
@@ -116,6 +116,8 @@
char *backup_dir = NULL;
int rsync_port = RSYNC_PORT;
int link_dest = 0;
+int checksum_seed = 0;
+int checksum_seed_set;
int verbose = 0;
int quiet = 0;
@@ -274,6 +276,7 @@
rprintf(F, --bwlimit=KBPS limit I/O bandwidth, KBytes per
second\n);
rprintf(F, --write-batch=PREFIXwrite batch fileset starting with
PREFIX\n);
rprintf(F, --read-batch=PREFIX read batch fileset starting with
PREFIX\n);
+ rprintf(F, --checksum-seed=NUM set MD4 checksum seed\n);
rprintf(F, -h, --help show this help screen\n);
#ifdef INET6
rprintf(F, -4 prefer IPv4\n);
@@ -293,7 +296,7 @@
OPT_COPY_UNSAFE_LINKS, OPT_SAFE_LINKS, OPT_COMPARE_DEST, OPT_LINK_DEST,
OPT_LOG_FORMAT, OPT_PASSWORD_FILE, OPT_SIZE_ONLY, OPT_ADDRESS,
OPT_DELETE_AFTER, OPT_EXISTING, OPT_MAX_DELETE, OPT_BACKUP_DIR,
- OPT_IGNORE_ERRORS, OPT_BWLIMIT, OPT_BLOCKING_IO,
+ OPT_IGNORE_ERRORS, OPT_BWLIMIT, OPT_BLOCKING_IO, OPT_CHECKSUM_SEED,
OPT_NO_BLOCKING_IO, OPT_WHOLE_FILE, OPT_NO_WHOLE_FILE,
OPT_MODIFY_WINDOW,
Re: Storage compression patch for Rsync (unfinished)
Is there any reason why caching programs would need to set the value, rather than it just being a fixed value? I think it is hard to describe what this is for and what it should be set to. Maybe a --fixed-checksum-seed option would make some sense, or for a caching mechanism to be built in to rsync if it is shown to be very valuable. A fixed value would be perfectly ok; the same magic value that batch mode uses (32761) would make sense. I know people have proposed some caching mechanisms in the past and they've been rejected for one reason or another. One difficulty is that additional files, or new file formats, are needed for storing the checksums, and that moves rsync further away from its core purpose. I don't think I'll include the option in 2.5.6. If I submitted a new patch with --fixed-checksum-seed, would you be willing to at least add it to the patches directory for 2.5.6? I will be adding block and file checksum caching to BackupPC, and that needs --fixed-checksum-seed. This will save me from providing a customized rsync (or rsync patches) as part of BackupPC; I would much rather tell people to get a vanilla 2.5.6 rsync release and apply the specific patch that comes with the release. Craig -- 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: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
Dave Dykstra wrote: On Sun, Jan 26, 2003 at 08:54:19PM -, Max Bowsher wrote: Dave Dykstra wrote: Alright. Max, could you quickly verify if the latest CVS version works OK for you on Cygwin? What, in particular? I'm not a very good testcase, because I use binary mounts and unix line endings everywhere. It compiles and does syncs with remote rsync daemons, which is my normal usage. Max. See if exclude files with DOS line endings work ok for you, and also the other config files if you can. Sorry, I don't have time to fiddle around to that extent right now. If you need to get 2.5.6 out the door, then do. If the Cygwin 2.5.6-1 doesn't work quite right, there can always be a 2.5.6-2. Max. -- 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: Storage compression patch for Rsync (unfinished)
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
Is there any reason why caching programs would need to set the
value, rather than it just being a fixed value?
I think it is hard to describe what this is for and what it should be
set to. Maybe a --fixed-checksum-seed option would make some sense,
or for a caching mechanism to be built in to rsync if it is shown to
be very valuable.
A fixed value would be perfectly ok; the same magic value that batch
mode uses (32761) would make sense.
I know people have proposed some caching mechanisms in the past and
they've been rejected for one reason or another.
One difficulty is that additional files, or new file formats, are needed
for storing the checksums, and that moves rsync further away from its
core purpose.
I don't think I'll include the option in 2.5.6.
If I submitted a new patch with --fixed-checksum-seed, would you be
willing to at least add it to the patches directory for 2.5.6?
I will be adding block and file checksum caching to BackupPC, and
that needs --fixed-checksum-seed. This will save me from providing
a customized rsync (or rsync patches) as part of BackupPC; I would
much rather tell people to get a vanilla 2.5.6 rsync release and
apply the specific patch that comes with the release.
Block checksums come from the receiver so cached block
checksums are only useful when sending to a server which had
better know it has block checksums cached. It should be
relatively easy to add a test prior to setup_protocol()
to determine if block checksums are cached. Given those
circumstances it shouldn't be necessary to add any
command-line option for this. Further, that test could
set the checksum_seed so setup_protocol could test
checksum_seed to see if it is alread set and not alter it
eliminating the need for a checksum_seed_set.
In fact doing as above and moving checksum_seed =
FIXED_CHECKSUM to the places in options.c where read_batch
and write_batch are set would allow reducing the
checksum_seed portion of setup_protocol like so:
if (remote_version = 12) {
if (am_server) {
- if (read_batch || write_batch) /* dw */
- checksum_seed = 32761;
- else
- checksum_seed = time(NULL);
+ if(!checksum_seed) checksum_seed = time(NULL);
write_int(f_out,checksum_seed);
} else {
checksum_seed = read_int(f_in);
}
}
Not only simplifying the code but i think rendering it more
understandable.
To save someone from looking, checksum_seed is initialized
to 0 as part of the declaration in checksum.c
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
--
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: Storage compression patch for Rsync (unfinished)
Block checksums come from the receiver so cached block checksums are only useful when sending to a server which had better know it has block checksums cached. The first statement is true (block checksums come from the receiver), but the second doesn't follow. I need to cover the case where the client is the receiver and the client is caching the checksums. That needs a command-line switch, since the server would otherwise use time(NULL) as the checksum seed, which is then sent from the server to the client at protocol startup. I agree with your changes though: the command-line handling code can set checksum_seed if any of write-batch, read-batch, or fixed-checksum-seed are specified, avoiding the additional variable. Craig -- 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: Storage compression patch for Rsync (unfinished)
On Sun, Jan 26, 2003 at 06:04:52PM -0800, Craig Barratt wrote: Block checksums come from the receiver so cached block checksums are only useful when sending to a server which had better know it has block checksums cached. The first statement is true (block checksums come from the receiver), but the second doesn't follow. I need to cover the case where the client is the receiver and the client is caching the checksums. That needs a command-line switch, since the server would otherwise use time(NULL) as the checksum seed, which is then sent from the server to the client at protocol startup. OK. I'll buy that as a possibility worth allowing for. This can be another option like --server, --daemon and --sender, neither discussed on the rsync manpage with normal options nor listed in USAGE. That will eliminate user confusion. Someday we should probably get a writup that covers these protocol oriented command-line options and succinctly discusses the issues of what the sender and receiver do. The whitepaper (i reviewd it recently) is nice for describing the theory and all the math but the pertinant implimentation issues are neglected. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- 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: Storage compression patch for Rsync (unfinished)
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote: Is there any reason why caching programs would need to set the value, rather than it just being a fixed value? I think it is hard to describe what this is for and what it should be set to. Maybe a --fixed-checksum-seed option would make some sense, or for a caching mechanism to be built in to rsync if it is shown to be very valuable. A fixed value would be perfectly ok; the same magic value that batch mode uses (32761) would make sense. I know people have proposed some caching mechanisms in the past and they've been rejected for one reason or another. One difficulty is that additional files, or new file formats, are needed for storing the checksums, and that moves rsync further away from its core purpose. I don't think I'll include the option in 2.5.6. If I submitted a new patch with --fixed-checksum-seed, would you be willing to at least add it to the patches directory for 2.5.6? I will be adding block and file checksum caching to BackupPC, and that needs --fixed-checksum-seed. This will save me from providing a customized rsync (or rsync patches) as part of BackupPC; I would much rather tell people to get a vanilla 2.5.6 rsync release and apply the specific patch that comes with the release. Sorry, but I don't think it would be good to do even that until we've all had a chance to look at what's involved in the caching and whether or not it would make better sense to have it be a modification to rsync rather than mostly external. I'm concerned that people might misuse the option without understanding the consequences. You could always keep the patch on the BackupPC web site in the meantime. - Dave -- 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: Cygwin issues: modify-window and hangs
On Sat, Jan 25, 2003 at 06:32:08PM +0100, Greger Cronquist wrote: --- Max Bowsher [EMAIL PROTECTED] skrev: Dave Dykstra wrote: I'm using the current Cygwin release (rsync-2.5.5-2). That is rsync-2.5.5, with an added msleep(30) which is intended to deal with a possible problem with signals in Cygwin. Making that msleep(100) works even better for me. Ah, I found the messages that were discussing this and I see this was supposed to prevent hangs at the ends of runs. I went ahead and put an msleep(100) in before the final kill...USR2 in main.c do_recv(). I also finally remembered that the calls to shutdown() were for Connection reset by peer errors and not hangs. I went ahead and put in a define SHUTDOWN_ALL_SOCKETS which is only set by configure on Cygwin and call shutdown when it is set. Hopefully that will get rid of messages. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsync-2.5.5 HPUX 11.0
Hello rsync-2.5.5 for hp-ux 11.0 is not syncing files more that 2 GB ( largefile ) . Should i need to recompile rsync ? Should i use any special options while compiling ? please help. -babu __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- 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: Cygwin issues: modify-window and hangs
http://lists.samba.org/pipermail/rsync/2002-August/008130.html but it still experienced hangs. It wasn't clear if the patch reduced the frequency or not. It didn't fix it for us. We sync Win9x clients to a Win2k server running rsync as service. Hangs and connection reset by peer happened almost daily. Adding a -B 16384 seemed to help, but we still get the error. I lack the knowledge to debug this problem by myself, but I if somebody wants to run some tests or try a patch with our setup, I'll be very happy to help. Regards, Carlos Gutiérrez [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
one more day of delay for release of 2.5.6
Well I was hoping to get the 2.5.6 out today, but I think I made too many Cygwin changes this evening for comfort and I'd like to allow one more day of testing. Cygwin users, please test as much as you can and post any problems. - Dave Dykstra -- 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: Cygwin issues: modify-window and hangs
Has *anybody* been able to figure out a fix for this that really works? Why does the receiving child wait in a loop to get killed, rather than just exit()? I presume cygwin has some problem or race condition in the wait loop, kill and wait_process(). The pipe to the parent will read 0 bytes (EOF) on the parent side after the child exits. Although I haven't tried it, I would guess this should be the reliable solution on all platforms. But there must be some good reason the wait loop, kill and wait_process() contortions appeared in the code (maybe some race condition with the remote side?)... Craig -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
CVS update: rsync
Date: Sun Jan 26 19:37:54 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv18282 Modified Files: authenticate.c Log Message: File I/O already handles '\r', so we can remove the O_TEXT flags. Revisions: authenticate.c 1.21 = 1.22 http://www.samba.org/cgi-bin/cvsweb/rsync/authenticate.c?r1=1.21r2=1.22 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Jan 26 20:08:14 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv21185 Modified Files: clientserver.c Log Message: Got rid of O_TEXT_STR change. Revisions: clientserver.c 1.103 = 1.104 http://www.samba.org/cgi-bin/cvsweb/rsync/clientserver.c?r1=1.103r2=1.104 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Jan 26 20:09:02 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv21431 Modified Files: syscall.c Log Message: Added back the O_BINARY #ifdef. Revisions: syscall.c 1.25 = 1.26 http://www.samba.org/cgi-bin/cvsweb/rsync/syscall.c?r1=1.25r2=1.26 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Jan 26 20:10:23 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv21467 Modified Files: exclude.c Log Message: Got rid of O_TEXT_STR and added code to strip '\r' from the end of the lines we read. Revisions: exclude.c 1.47 = 1.48 http://www.samba.org/cgi-bin/cvsweb/rsync/exclude.c?r1=1.47r2=1.48 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Jan 26 20:11:16 2003 Author: wayned Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv21582 Modified Files: rsync.h Log Message: Got rid of recent O_TEXT* and O_BINARY* changes. Revisions: rsync.h 1.135 = 1.136 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.h?r1=1.135r2=1.136 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Sun Jan 26 20:49:25 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv24320 Modified Files: NEWS Log Message: Change news item about handling of text mode in files to just permitting any of the standard line termination styles. Revisions: NEWS1.94 = 1.95 http://www.samba.org/cgi-bin/cvsweb/rsync/NEWS?r1=1.94r2=1.95 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Mon Jan 27 02:48:14 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv24648 Modified Files: rsync.1 rsync.yo Log Message: Change erroneous references to a --config-file option to the correct --config option. Revisions: rsync.1 1.126 = 1.127 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.126r2=1.127 rsync.yo1.111 = 1.112 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.111r2=1.112 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Mon Jan 27 03:07:18 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv27629 Modified Files: rsyncd.conf.5 rsyncd.conf.yo Log Message: Update rsyncd.conf documentation to be right for rsync server mode over a remote shell. Revisions: rsyncd.conf.5 1.47 = 1.48 http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.5?r1=1.47r2=1.48 rsyncd.conf.yo 1.52 = 1.53 http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.yo?r1=1.52r2=1.53 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Mon Jan 27 03:13:46 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv28080 Modified Files: rsync.1 rsync.yo Log Message: Update date on man page. Revisions: rsync.1 1.127 = 1.128 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.127r2=1.128 rsync.yo1.112 = 1.113 http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.112r2=1.113 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Mon Jan 27 03:36:54 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv29806 Modified Files: TODO Log Message: Remove the Connection reset by peer from TODO Revisions: TODO1.67 = 1.68 http://www.samba.org/cgi-bin/cvsweb/rsync/TODO?r1=1.67r2=1.68 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
CVS update: rsync
Date: Mon Jan 27 03:52:42 2003 Author: dwd Update of /data/cvs/rsync In directory dp.samba.org:/tmp/cvs-serv30858 Modified Files: NEWS main.c Log Message: Insert a 100ms sleep just before sending the USR2 signal to the child receiver process to prevent some hangs on Cygwin. Anthony Heading discovered the workaround first and suggested 30ms, and Greger Cronquist had better luck with 100ms. Revisions: NEWS1.96 = 1.97 http://www.samba.org/cgi-bin/cvsweb/rsync/NEWS?r1=1.96r2=1.97 main.c 1.158 = 1.159 http://www.samba.org/cgi-bin/cvsweb/rsync/main.c?r1=1.158r2=1.159 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
