similar to: 3.0.2: make_bak_dir mkdir ...: File exists (17)

Rare and intermittent message groups suggest a race condition ... ? Here's the pattern of messages: rsync: make_bak_dir mkdir <path> failed: File exists (17) rsync: keep_backup failed: <path> -> <path>: No such file or directory (2) rsync: stat <path> failed: No such file or directory (2) How rarely? We run a scripted rsync daily on ~50 personal computers and

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 have users running rsync 3.0.6 on Mac OS 10.5 and 10.6 with the following arguments (for example): rsync -aNHAXx --fileflags --force-change --no-inc-recursive --delete-during --filter="P _Archive*" --filter="P /*" --backup --backup-dir="_Archive_2010_March_07_22-27-43" / /Volumes/Backup I can't seem to figure out how make_bak_dir could be returning this error

Through several versions up to and including the current 3.0.9 I experience sporadic, repeating (but not predictably) errors of this form: > rsync: make_bak_dir mkdir "/REPO/backup/XXXX-data1-20120727-040453" failed: File exists (17) > rsync: keep_backup failed: "/REPO/backup/XXXX-data1/data1/A182/tb5178/tb5178.hebb/out.TENT_warn.txt" ->

All callers of robust_rename() call copy_file() if EXDEV is received. This patch moves the copy_file() call into robust_rename(). Patch Summary: -12 +1 backup.c -15 +2 rsync.c -9 +33 util.c -------------- next part -------------- patchwork diff util.c --- util.c 2004-02-17 09:58:44.000000000 -0500 +++ util.c 2004-02-17 10:21:22.000000000 -0500 @@ -355,16 +355,40 @@

I tried rsync 2.6.1cvs on my FreeBSD 4.X boxes. It dumps core when preserve_hard_links and backup. And SUPPORT_HARD_LINKS is true. rsync -avH --delete --backup --backup-dir=/some/backup/dir \ srchost::dir/ dir/ The core says... ------------------------------------------------------------------------ Program terminated with signal 11, Segmentation fault. #0 0x80536c0 in keep_backup

I have seen some talk about this but have not seen any answers. I know this is a problem on CentOS 7.1 and I also think it is a problem on CentOS 7.0. Basically if I have an NFS client only config - meaning that the nfs-server.service is not enabled then I have to wait 60 seconds after boot for the 1st NFSV3 mount to succeed. What I can surmise is the following. I attempt to perform a NFS

Running rsync 2.4.7pre1, using the --backup-dir option, I just realized today that file ownerships and permissions of backed up files are not preserved. In other words, if rsync moves an obsolete file to the backup dir, it's ownership seems to revert to root:root, and permissions change, as well. We are also using the -a (archive) option, by the way, which should mean "preserve

Hi: Suppose I have the following files on my target volume: /Applications/[45,000 sub files and directories] /Developer/[120,000 sub files and directories] ... (another 8 or so directories with lots of files and sub directories) /usr/ [75,000 sub files and directories] For a total of approximately 500K files and directories. On my source, I have only a handful of items: /Data/ [70 items]

https://bugzilla.samba.org/show_bug.cgi?id=2758 Summary: "File exists" error using options -b and --backup-dir with device files. Product: rsync Version: 2.6.4 Platform: All OS/Version: AIX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

That is the thing - rpc.statd does have rpcbind a pre-req. It looks like systemd is not handling this correctly. Just wondering if anyone knows a good way to fix. root at ls2 /usr/lib/systemd/system 110# grep Requires rpc-statd.service Requires=nss-lookup.target rpcbind.target On 8/30/15 7:45 PM, Rob Kampen wrote: > On 08/31/2015 01:39 PM, Mark Selby wrote: >> I have seen some talk

i found the following also .. Aug 7 08:44:10 rtd-print1 autofs[15991]: Starting automount.... Aug 7 08:48:26 rtd-print1 autofs[16291]: Stopping automount.... Aug 7 08:48:27 rtd-print1 automount[16302]: syntax error in map near [ * server.internal.domain.tld: ] Aug 7 08:48:27 rtd-print1 autofs[16297]: Starting automount.... Aug 7 08:48:46 rtd-print1 rpcbind: rpcbind terminating on signal.

I am try to use rsync from my windows box (under cygwin) to back up "My Documents" on to a debian server (known on my home network as roo.home) running rsyncd from inetd where it is run as root. my rsyncd.conf file sets the gid and uid to user backup.backup thusly:- syslog facility = daemon uid = backup gid = backup hosts allow = 192.168.0.0/24 hosts deny = 0.0.0.0/0 timeout = 600

Any help here? I have included all of the output of the suggested diags that Thomas said I should run, but I admit that I'm not sure what I'm looking for, as I'm not familiar with RPC functionality on Linux. Something is not working with RPC on my Samba 4.0.3 server. (FWIW, it doesn't work with IPTables stopped either.) > On Mon, Feb 25, 2013 at 2:21 PM, Mike Stroven wrote:

This config is working fior me, with just using an older kernel. [root at mnemosyne ~]# uname -r 3.10.0-514.21.2.el7.x86_64 [root at mnemosyne ~]# rpm -qa | grep rpcbind rpcbind-0.2.0-42.el7.x86_64 [root at mnemosyne ~]# rpm -qa | grep nfs libnfsidmap-0.25-17.el7.x86_64 nfs-utils-1.3.0-0.48.el7.x86_64 Patrick -- =================================================================== | Equipe

On 2/6/2017 10:40 ??, Philippe BOURDEU d'AGUERRE wrote: > Reverting to rpcbind-0.2.0-38.el7 solves the problem for me Thank you very much Philippe, I notice that I have upgraded to rpcbind-0.2.0-38.el7_3.x86_64 on May 26. Have you checked if this bug/behavior has been reported or should we file a bug report? Nick

Hello, MERRY CHRISTMAS to all in list! After I upgraded to latest: CentOS Linux release 7.7.1908 (Core) I am facing nfs crashes which cause the system to hang frequently. This is caused by cp to nfs-mounted shares. Below is dmesg output; you will see call traces. These cause system to gradually overload: [root at hesperia1 ~]# top top - 10:09:40 up 10:16,? 1 user,? load average: 53.66,

Local end (receiving): 3.0.2, 3.0.3pre2 Remote end (sending): 2.6.9 Under 3.0.x, rsync sometimes prints an "Invalid argument" error when moving sockets to the backup directory (--backup-dir): rsync: mknod "/backup/machine/../machine-before-4/var/run/audit_events" failed: Invalid argument (22) The problem appears to be that, at least with sockets, keep_backup() is calling

When I perform a rsync with backup I get 100's of: make_bak_dir mkdir "/export/giger.back.....eary/java/weka/gui" failed: File exists make_bak_dir mkdir "/export/giger.back....ary/java/weka/gui" failed: File exists make_bak_dir mkdir "/export/giger.back...ary/java/weka/gui" failed: File exists . . . My backup command is: rsync -q --backup

Hello, I use rsync for incrmental backups in the following way: rsync \ $EXCLUDE \ -e ssh \ --archive \ --numeric-ids \ --compress \ --relative \ --one-file-system \ --cvs-exclude \ --delete \ --delete-excluded \ --bwlimit=0 \ --backup \ --suffix='' \ --backup-dir=$BACKUP_ROOT/$BACKUP_HOST/${TODAY} \ $BACKUP_HOST_AND_PATH