[PATCH] Fix issue 1763 by stripping \r from gitpatch reported path
Bill Barry
after.fallout at gmail.com
Fri Jul 24 15:10:45 CDT 2009
Eric M. Hopper wrote:
> On Fri, 2009-07-24 at 16:27 +0000, Bill Barry wrote:
>
>> # HG changeset patch
>> # User Bill Barry <after.fallout at gmail.com>
>> # Date 1248452792 21600
>> # Node ID 384618d1871a0923aa1715fcdd8d227a66e0455c
>> # Parent 65719472bfa2cde9630b2fc019688d95327d3e69
>> Fix issue 1763 by stripping \r from gitpatch reported path
>>
>> diff --git a/mercurial/patch.py b/mercurial/patch.py
>> --- a/mercurial/patch.py
>> +++ b/mercurial/patch.py
>> @@ -1022,7 +1022,7 @@
>> for gp in gitpatches:
>> if gp.op in ('COPY', 'RENAME'):
>> copyfile(gp.oldpath, gp.path, cwd)
>> - changed[gp.path] = gp
>> + changed[gp.path.rstrip('\r')] = gp
>> else:
>> raise util.Abort(_('unsupported parser state: %s') % state)
>>
>
> As an item of curiosity, how do git patches currently handle filenames
> with control characters in them?
I have no idea. Perhaps that is a better question for the list at large?
I merely came across this as part of trying to figure out why attic
wasn't working on windows this week after I did some updates. I am not
convinced that this is a good solution to the problem either (pmezard
stated in bts that diff headers are supposed to be LF only endings no
matter where they come from, but I have been able to generate CRLF
headers in several different ways that I have generated a patch). This
patch will certainly not work with any files that legitimately have CR
chars at the end of them (though I suspect that files which have LF
would break the diff header format system as well; other control
characters are probably safe in that they aren't dealt with explicitly).
I think it would be best if at all possible to not use any control chars
in a file name as weird things may very well happen with many different
systems. If it were up to me I would say control chars are disallowed in
filenames (and the only things we would have to worry about would be
exploits for them). I would hazard to guess there is probably problems
with certain unicode filename chars as well (filenames should be bytes,
not code points, and for that matter code points should not have bytes
that could be read as control chars when processed on a per-byte basis;
the whole thing is fubared pretty badly).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20090724/57cb9f52/attachment.htm
More information about the Mercurial-devel
mailing list