similar to: [Bug 1536] rsync aborts transferring files larger than 2 GB

Dear rsync-developers, on AIX5.1 with 32-bit kernel one can have large-file support. rsync in principle supports it correctly since the flag _LARGE_FILES is treated correctly in the /usr/include/*.h But there is one point missing, the mkstemp is not opening a large file. So syncing large files crash after 2GB. To avoid this one could either put a #ifdef _LARGE_FILES #undef HAVE_SECURE_MKSTEMP

I have discovered that rsync 2.5.6 uses the mkstemp() routine wich do not have a 64bits version into the AIX libc. A very simple workaround to the big files writing rsync pb. is to not use this routine that create files w/ mkstemp() by modifying the "syscall.c" source file at line 154 as following : #if defined(HAVE_SECURE_MKSTEMP) && defined(HAVE_FCHMOD) become #if

For all you folks out there using rsync on HP-UX, be warned that HP-UX is still broken with regard to large files. I opened a bug report with HP last year, as described here: http://lists.samba.org/archive/rsync/2004-July/010226.html I've been periodically checking on the status and today I was told that it's been officially filed as a "we won't fix this", citing that the

https://bugzilla.samba.org/show_bug.cgi?id=1536 Summary: rsync aborts transferring files larger than 2 GB Product: rsync Version: 2.6.2 Platform: PA-RISC OS/Version: HP-UX Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: vieser@porsche.de

On Mon, 2 Aug 2004, Wayne Davison wayned-at-samba.org |Rsync List| wrote: > Would anyone who is seeing this problem please try out the patch that is > attached to this bugzilla bug: > > https://bugzilla.samba.org/show_bug.cgi?id=1536 I gave it a test and it seems to work fine on HPUX 11.0. It skips the problematic mkstemp() call. It also passed the largefiles test that I sent

We are trying to enable large file support for everything built for ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version for compatibility with open64. When looking into enabling the large file support flags, I noticed: `void start_progress_meter(const char *, off_t, off_t *);` in progressmeter.h which would have different ABIs with and without large file support. You all

On Wed, 22 Mar 2023, Allen Webb wrote: > We are trying to enable large file support for everything built for > ARM on ChromeOS and openssh uses mkstemp which has a 64-bit version > for compatibility with open64. When looking into enabling the large > file support flags, I noticed: > > `void start_progress_meter(const char *, off_t, off_t *);` > > in progressmeter.h

I can't make R on a Solaris 9 box. Does anyone have any suggestions? Thanks in advance. <3>-> make `Makedeps' is up to date. `libbz2.a' is up to date. `Makedeps' is up to date. `libpcre.a' is up to date. `Makedeps' is up to date. `libz.a' is up to date. ../../../src/include/libintl.h is unchanged ../../../include/libintl.h is unchanged `localecharset.h'

Hi, Arvind Sudarsanam: I know some of Open64. Above all, Open64 is designed for a high performance compiler. It is now supported by AMD, HP, ICT Chinese Academy of Science, etc. and has been ported to X86, Itanium, Loongson CPU etc. And to your questions 1, Open64 already have some main optimization phases, Inline for aggressive inline opt. LNO for loop opt, WOPT for machine independent opt(

Hi, I have been working towards developing compiler optimization tools targeting multi core processors while using LLVM IR as the starting point and building on top of the analysis and optimization passes available in the llvm source. Recently, I looked into Open64 and its intermediate representation WHIRL. Documentation for developers to use Open64 seems to be inadequate (when compared to LLVM

On 11/08/2013 09:12 AM, Steve Capper wrote: > diff --git a/usr/klibc/open64.c b/usr/klibc/open64.c > new file mode 100644 > index 0000000..6ca603e > --- /dev/null > +++ b/usr/klibc/open64.c > @@ -0,0 +1,22 @@ > +/* > + * open64.c > + * > + * For 64 bit systems without the open syscall, pass straight > + * through into openat. > + */ > + > +#define

Hi, Gang: I remember there were different voices when you check-in the code. I agree with them although I didn't reply your mail in open64's mailing list. In the transformation you illustrate, it involves two operations: 1) promote WHILE-loop into DO-loop (i.e noncountable loop to countable loop) 2) get rid of trip-count dec/inc and compare. 1) is irrelevant to HW loop.

Hi, on AIX, mkstemp doesn't open a file with the O_LARGEFILE option, so you can't transfer files > 2GB to an AIX machine. Here is a fix: diff -c -r rsync-2.5.6.orig/syscall.c rsync-2.5.6/syscall.c *** rsync-2.5.6.orig/syscall.c Sun Jan 26 21:09:02 2003 --- rsync-2.5.6/syscall.c Wed May 14 13:55:15 2003 *************** *** 151,157 **** if (dry_run) return -1; if

Hi, I just wanted to relate the solution to a problem I was having to hopefully save someone else a day of frustration. I'm using rsync-2.5.5 on AIX 4.3, compiled with gcc 2.95.3. The file I was sync'ing was very large (>2GB). Despite being configured with --enable-largefiles (which #defines _LARGE_FILES properly for AIX), and despite the fact that the initial transfer of said file

I am the designer for open64 hwloop structure, but I am not a student. Hope the following helps: To transform a loop into hwloop, we need the help from optimizer. For example, while(k3>=10){ sum+=k1; k3 --; } into the form: zdl_loop(k3-9) { sum+=k1; } So, we introduce a new ZDLBR whirl(open64 optimizer intermediate) operator, which represents the loop in whirl as:

On Tue, Nov 13, 2012 at 11:23:02PM -0800, Shuxin Yang wrote: > Hi, All: > > Is it legal to delete empty infinite loop like this : "while(1) {}"? > It is interesting that both llvm and gcc keep the loop, however Open64 > delete it. I think it's illegal to delete such infinite loop, perhapes you should file a bug report to open64. That's my 2 cents.

On Wed, Nov 14, 2012 at 03:32:53PM +0800, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Nov 13, 2012 at 11:23:02PM -0800, Shuxin Yang wrote: > > Hi, All: > > > > Is it legal to delete empty infinite loop like this : "while(1) {}"? > > It is interesting that both llvm and gcc keep the loop, however Open64 > > delete it. > > I think it's illegal

Hi there, I have a problem when I try to create a new user with swat. I use binaries of Samba 2.2.2 coming from www.samba.org, or from www.sunfreeware.com on Solaris 2.6 and on 8. I compiled the sources and the result is the same. When I click on "Add New User" (Server Password Management), I receive a nearly blank page: I can only see the samba gif on top and the user is not

Hi shuxin, Promote while-loop to do-loop is the job of loop induction recognized, not this transformation. The scalar transform for hwloop in optimizer is for that it is a trouble to discriminate trip counting code with the real production code stuff and do the elimination in cg, we have to write customized code to handle this general stuff in ervey targets. So, we take the help from optimizer

Hi all, We did some benchmarks on code size with clang, gcc 4.5, and open64. Clang performed second in the test. The benchmark is CSiBE. Clang can't compile the linux kernel (some inline asm not supported) and replaypc (error: use of unknown builtin '__builtin_next_arg'). The concrete results are attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: