similar to: Incremental file-list recursion has landed in CVS

here (in keep_backup())? --- backup.c.orig Mon Dec 9 17:02:36 2002 +++ backup.c Mon Dec 9 17:03:50 2002 @@ -273,6 +273,7 @@ /* move to keep tree if a file */ if(!kept) { + make_bak_dir(fname,backup_dir); if (!robust_move (fname, keep_name)) rprintf(FERROR, "keep_backup failed %s -> %s : %s\n", fname, keep_name, strerror(errno)); this reconstructs parent

I am experimenting with Matt McCutchen's excellent continusync script, and I'm having an issue. (My copy of continusync has been modified from the original http://mattmccutchen.net/utils/continusync by adding this @ line 227: <$fromInwt>; as suggested by Matt.) The problem is easily reproduced: # mkdir ~/foo # continusync ~/foo root@remotehost:~/foo & # vi

Dear rsync people (particularly Wayne), I am finding that the CVS version of rsync hangs during most, but not all, local copies. The problem goes away if I pass --protocol=29, so I'm guessing it is related to the incremental file-list sending. The hanging seems to be timing-dependent. Increasing the verbosity level seems to increase the chance of a hang. If I run rsync repeatedly with the

http://bugzilla.mindrot.org/show_bug.cgi?id=819 Summary: patch to add kerberos password-changing Product: Portable OpenSSH Version: 3.8p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: enhancement Priority: P2 Component: Kerberos support AssignedTo: openssh-bugs at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=808 Summary: segfault if not using pam/keyboard-interactive mech and password's expired Product: Portable OpenSSH Version: 3.8p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: PAM support

Dear rsync people, I have finally made packages for rsync 2.6.8 with ACL support. You can download a prepatched source package and RPMs from here: http://www.kepreon.com/~matt/myrsync/ Or you can use this yum repository: http://www.kepreon.com/~matt/rpm/ The RPM is called rsync-acl so automatic updating tools will know not to toss it in favor of plain rsync, but it "Provides" rsync

Dear Wayne, C Sights, and list, I have started working on my rewritten version of the rsync man page. So far, I have redone the top of the man page and the list of options; I improved many of the one-line option descriptions. The yodl and man versions of my man page are available here and here: http://www.kepreon.com/~matt/private/rsync-new-manpage/rsync.yo

http://bugzilla.mindrot.org/show_bug.cgi?id=563 Summary: getaddrinfo() in libopenbsd-compat.a breaks heimdal- linked pam_krb5 Product: Portable OpenSSH Version: -current Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Miscellaneous

https://bugzilla.samba.org/show_bug.cgi?id=5220 Summary: PATCH SUBMITTED: New Feature: stdio model for client Product: rsync Version: 3.0.0 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy:

https://bugzilla.samba.org/show_bug.cgi?id=3828 Summary: ACLs are not supported on this client Product: rsync Version: 2.6.8 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: marc@perkel.com QAContact:

Wayne, Sven's note made me curious about how much incremental recursion actually reduces memory usage, so I'm asking: How much of the file list do the rsync processes hold in memory at any one time in incremental recursion mode? Just the active file-list chunk(s) and their ancestors? Or does rsync store directories or even all files permanently until the end of the run? I could

https://bugzilla.samba.org/show_bug.cgi?id=5266 Summary: Duplicate "not creating new directory" output w/ incremental recursion Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: minor Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=6719 Summary: I/O error protection is broken w/ protocol 30 and incremental recursion Product: rsync Version: 3.0.6 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P3 Component: core AssignedTo: wayned at

Hello, I'm using rsync 3.0.3 over ssh to sync data between two hosts. I can't get the incremental recursion working: rsync -vLogtprz --progress --delete --delete-during --partial -e "ssh -p 1234" --numeric-ids user at host /local/dir/ The documentation states that the only thing which disables incremental recursion is not using delete-during (or disabling it by --no-i-r).

https://bugzilla.samba.org/show_bug.cgi?id=7862 Summary: hard-links and incremental recursion: unclear what happens Product: rsync Version: 3.0.7 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

We have an application that was build on a windows platform that expects a case insensitive file system. Is there a way to set one up in CentOS? NTFS should work, I think, but I feel uneasy using that under Linux. Russ

I wonder if it would be possible to provide R patched and development versions for Windows as simple zip files without using any installers. There are more and more free and open source software projects providing such portable versions, among them Python (since V2.5), the new MikTex 2.8, OpenOffice 3, Firefox and Thunderbird, to name a few. Many smaller Windows utilities do the same. When

Is this a known issue? rsync does not always preserve dates and permissions on symbolic links, and while the -i option indicates it is trying to bring things in sync, it does not. Maybe between OS's that have sufficiently different implementations, this is not possible.

On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote: > The cpu argument in the function prototype of vcpu_is_preempted() > is changed from int to long. That makes it easier to provide a better > optimized assembly version of that function. > > For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the > downcast from long to int is not a problem as vCPU number

According to the schedule (e.g. on the right on llvm.org), we should have tagged the release by now, but we haven't, so we're officially behind schedule. I'm still optimistic that we can wrap this up pretty soon, though. This is what's blocking us: - PR26509: Crash in InnerLoopVectorizer::vectorizeLoop() I'm waiting to hear what Cong comes up with, otherwise we can revert