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>