Re: patch2.5.9 fails on some dos generated patches

[Paul Eggert]

Toshio <address@hidden> writes:

> In patch-2.5.9, the code that scans the header in unidiff's (and ed
> diff's) was removed.  This fixes the bug in the previous version.
> However, it was discovered that some patches would no longer apply with
> this code.  Further investigation revealed that the original file had LF
> EOL encoding and the diff file had CRLF encoding.

Can you please give an example of the original and diff files here?

Suppose the diff file was produced on Unix, and was later corrupted by
appending CR to every line of the diff file.  Then "patch" should
discover this, and should ignore the CR.

Conversely, suppose the old and new files are corrupted by appending
CR to every line, and then a Unix "patch" is run on the result.  Then
some lines of the diff file will end in CRLF, and other lines won't.
It sounds like you may be talking about this kind of corruption, but
I'm not familiar enough with the details to know whether "patch"
should be able to recover from this.

> Can someone tell me what the expected behaviour of diff and patch are
> when dealing with CRLF files?  Should it be expected that generated
> diffs always contain the CRLF convention (in the patch body) of the
> original file?

"patch" is written from the Unix point of view, so it normally views
CR as just another character.  There are a few exceptions to this,
though, and one of the exceptions is when it attempts to detect CR
corruptin in the diff.  It does this by observing a CR where there
couldn't possibly be a CR in a conforming diff hunk, deducing that
corruption occurred, and then stripping trailing CR uniformly from the
rest of the diff hunk before attempting to analyze this further.

This heuristic is safe, since it never misinterprets a diff that was
properly generated on a Unix box, even if the diff deals with files
that actually have trailing CRs in their lines.

On a DOS platform, the underlying I/O routines may also strip CR on
their own, but this is a separate issue, one that "patch" proper
doesn't worry about much (if I recall correctly, it's a user-specified
option to use binary I/O).