similar to: [PATCH] rsync on cygwin - textmode config files

Ville Herva [mailto:vherva@niksula.hut.fi] 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

The second rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre2.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the

Hi As my cross platform registry editor (FRED available from https://www.pinguin.lu (sorry for advertising but I couldn't resist ;-))) is evolving, I recently added write support to it. While under Linux everything worked nice, the Windblows build didn't. It seems that Windows opens files by default in text mode (O_TEXT) which is a problem. The attached patch adds the O_BINARY flag to

On Thu, Jun 27, 2013 at 11:29:28PM +0200, Daniel Gillen wrote: > Hi > > As my cross platform registry editor (FRED available from > https://www.pinguin.lu (sorry for advertising but I couldn't resist > ;-))) is evolving, I recently added write support to it. > > While under Linux everything worked nice, the Windblows build didn't. > > It seems that Windows

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

https://bugzilla.samba.org/show_bug.cgi?id=5401 Summary: getpassf() should honor strict modes Product: rsync Version: 3.0.3 Platform: All OS/Version: OS/2 Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: steve53@earthlink.net

Hello, The attached patch should fix Debian bug #128632 (http://bugs.debian.org/128632). This bug happened because if an error occurred in writefd_unbuffered (such as the remote end closing the socket), it would call rprintf, which would call io_multiplexing_write, which would in turn call writefd_unbuffered, which would then just sit in a loop trying to write to the broken socket. Also, we

Folks, Just downloaded 2.5.2 to play with...builds with a raft of warnings, and the symlink test fails. Transcript below for anyone with the knowledge and energy to repair. This is done with gcc-3.0.3. David. ----- BUILD: corona 2.5.2 7 $ make gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c rsync.c -o rsync.o gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c generator.c -o

Did anyone have any luck compiling rsync 2.5.2, from source, on Mac OS X? Doing a straight ./configure && make, I get the error below. I've searched the lists here with no luck. Any pointers, or any URL with more info would be great. Thanks! RSYNC 2.5.2 COMPILING ERROR ON MAC OS X: root# make Please ignore warnings below about mktemp -- it is used in a safe way cc -g -O2

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

https://bugzilla.samba.org/show_bug.cgi?id=2000 Summary: mdfour.c calculates wrong result when block is a multiple of 64 bytes long. Product: rsync Version: 2.6.3 Platform: All OS/Version: Linux Status: NEW Severity: minor Priority: P3 Component: core AssignedTo:

I'm using the source-filter option in this patch with the command rsync.exe -a -v -e ssh --source-filter="/cygdrive/c/openssl.exe enc -des3 -pass pass:whatever -a" /cygdrive/c/backup user@dir: to crypt files to be sent at source with openssl. At some point rsync fails an i get 104435520 [main] rsync 1040 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 104436464 [main]

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

https://bugzilla.samba.org/show_bug.cgi?id=2000 wayned@samba.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From wayned@samba.org 2005-01-10 13:53

On the subject of needed patches, I just recently completed a patch for librsync that fixed the mdfour code to have uint_64 or 2 uint_32's for size. Without this, the checksums on files >512Megs are incorrect. The code should drop into rsync without a hitch. The same goes for mdfour in samba, becuase that is where librsync got the code from anyway. Robert Weber University of

Hi, attached is a patch which solves the following problem: Sometimes scp could hang in Cygwin when used as remote end using the -t option. This is due to a binmode/textmode problem which could be raised by the login shell which is used by the user and it's setting of textmode on stdin. The patch solves that problem by explicitly setting binmode on stdin. Besides solving the hanging

When I compile on Solaris * I get the foillowing errors: bash-2.03# gmake gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c rsync.c -o rsync.o gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c generator.c -o generator.o gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c receiver.c -o receiver.o gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c cleanup.c -o cleanup.o gcc

Building flac 1.0.3 under the latest cygwin craps out in src/libFLAC/file_decode.c and src/flac/file.c for _O_BINARY not being defined. It appears that #include <io.h> is not sufficient to pull in this macro; you need to #include <fcntl.h>. BTW, nice test suite! Talk about exhaustive. If anyone is interested in my Cygwin binaries (no Ogg support), I can provide an encap

I've run into a bug in the IO handling when reading a file. Suppose I have a file that lives on an NFS filesystem. That filesystem is NOT being exported with auth=0 permissions. So, if I try to access a file as root, it successfully opens the file, but subsequent reads fail with EACCES. This produces a destination file full of null bytes. I noticed this with 2.5.7, but checked 2.6.2 as

I'm getting following error while compiling rsync Can anyone help me . I'm running Alpha Server with TRU64 5.1 any help will be appreciated cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c rsync.c -o rsync.o cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c generator.c -o generator.o cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c receiver.c -o receiver.o cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c