osx 10.6 strange rsync errors

[Ira Cooke]

Hi Rob / Wayne,

Sorry for the slow reply Rob.

I'm not sure of the requirements for patches, but I think it would be useful to create one for this case as there are reasonably number of people affected.

I created a patch file against the current version (see below). 

Would it be possible to include this patch in the official list? 

Cheers
Ira



diff -Naur rsync-3.0.8_orig/receiver.c rsync-3.0.8_nodotdot/receiver.c
--- rsync-3.0.8_orig/receiver.c	2011-04-05 17:12:03.000000000 +1000
+++ rsync-3.0.8_nodotdot/receiver.c	2011-04-05 17:20:40.000000000 +1000
@@ -103,7 +103,10 @@
 		}
 	} else
 		f = fname;
-	fnametmp[length++] = '.';
+		
+	if ( f[0]!='.'){
+		fnametmp[length++] = '.';
+	}
 
 	/* The maxname value is bufsize, and includes space for the '\0'.
 	 * NAME_MAX needs an extra -1 for the name's leading dot. */




> Hi Vernon,
> 
> I don't know why I didn't think of that - I was telling people to exclude all . files! Thanks. I wonder if this is foolproof enough to create a patch since it seems to be an ongoing bug with OS releases.
> 
> Best,  Rob
> 
> On Feb 24, 2011, at 4:54 AM, Ira Cooke wrote:
> 
>> I've recently encountered this issue which was discussed here about a year ago. 
>> 
>> I'm not sure if anyone has a fix for this, but I thought I would post my workaround here. 
>> 
>> Since the topic is old, I'm summarising the problem .. basically it involves rsync creating large numbers of files with a leading ".." when syncing to an apple network share via afp. 
>> 
>> The essence of the problem is that there is an apple bug which causes weird phantom files to be created whenever an attempt is made to create a file with a leading ".."
>> 
>> As a workaround I figured the simplest thing to do would be to ensure that rsync only ever adds a "." when creating tmp files for filenames that do not already have a leading dot. 
>> 
>> I've attached a modified version of the get_tmpname method which simply wraps the addition of a "." in an if statement. 
>> 
>> I'd like to ask the list if you think this is a likely to have any issues (eg filename comparisons relying on a dot always being added). 
>> 
>> On my system this change seems to work around the problem pretty well. 
>> 
>> Thanks
>> Ira
>> 
>> ( Look for "Modified Code" so see my change )
>> 
>> int get_tmpname(char *fnametmp, const char *fname)
>> {
>> 	int maxname, added, length = 0;
>> 	const char *f;
>> 
>> 	if (tmpdir) {
>> 		/* Note: this can't overflow, so the return value is safe */
>> 		length = strlcpy(fnametmp, tmpdir, MAXPATHLEN - 2);
>> 		fnametmp[length++] = '/';
>> 	}
>> 
>> 	if ((f = strrchr(fname, '/')) != NULL) {
>> 		++f;
>> 		if (!tmpdir) {
>> 			length = f - fname;
>> 			/* copy up to and including the slash */
>> 			strlcpy(fnametmp, fname, length + 1);
>> 		}
>> 	} else
>> 		f = fname;
>> 		
>> 	// Modified Code 	
>> 	if ( f[0]!='.'){ 
>> 		fnametmp[length++] = '.';
>> 	} 
>> 	// End Modified Code 
>> 	
>> 	/* The maxname value is bufsize, and includes space for the '\0'.
>> 	 * (Note that NAME_MAX get -8 for the leading '.' above.) */
>> 	maxname = MIN(MAXPATHLEN - 7 - length, NAME_MAX - 8);
>> 
>> 	if (maxname < 1) {
>> 		rprintf(FERROR_XFER, "temporary filename too long: %s\n", fname);
>> 		fnametmp[0] = '\0';
>> 		return 0;
>> 	}
>> 
>> 	added = strlcpy(fnametmp + length, f, maxname);
>> 	if (added >= maxname)
>> 		added = maxname - 1;
>> 	memcpy(fnametmp + length + added, ".XXXXXX", 8);
>> 
>> 	return 1;
>> }
>> -- 
>> Please use reply-all for most replies to avoid omitting the mailing list.
>> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
>> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20110405/f2cea316/attachment.html>