Bug 234822

Same problem may also be in patch for RHEL5.

When one file name appears twice in a patch file, then patch doesn't backup the file properly. 

This really confuses quilt.

16:36 <grondo> I have a question. Does this seem like a bug?
16:37 <grondo> I have a patch that lists the same file twice, as if two dependent patches were concatenated together. So the first hunk patches the file, and then the second hunk patches it again, with context sensitive to the first hunk.
16:38 <neb> yeah that is kind of normal. The kernel team does that all the time.
16:38 <grondo> when I use patch --backup, the backup file is not the original it is the file + the first hunk/ So the sequence seems to be, backup file; apply first hunk; backup newly patched file, apply second hunk. Does that seem like a bug in patch?
16:39 <grondo> It *really* confuses quilt
16:41 <grondo> grondo@wopri /tmp/grondo >cat patchtest
16:41 <grondo> This is text in the original file.
16:41 <grondo> grondo@wopri /tmp/grondo >cat patchtest.patch
16:41 <grondo> --- patchtest   2007-02-07 16:31:15.000000000 -0800
16:41 <grondo> +++ patchtest.2 2007-02-07 16:31:41.000000000 -0800
16:41 <grondo> @@ -1 +1,3 @@ This is text in the original file.
16:41 <grondo> +
16:41 <grondo> +This is text added by patch1.
16:41 <grondo> --- patchtest   2007-02-07 16:31:41.000000000 -0800
16:41 <grondo> +++ patchtest   2007-02-07 16:32:09.000000000 -0800
16:41 <grondo> @@ -1,3 +1,6 @@
16:41 <grondo> +This is text added by patch2.
16:41 <grondo> + This is text in the original file.
16:41 <grondo> This is text added by patch1.
16:41 <grondo> +
16:41 <grondo> grondo@wopri /tmp/grondo >patch --backup -p0 < patchtest.patch
16:41 <grondo> patching file patchtest
16:41 <grondo> patching file patchtest
16:41 <grondo> grondo@wopri /tmp/grondo >cat patchtest.orig
16:41 <grondo> This is text in the original file.
16:41 <grondo> This is text added by patch1.
16:42 <neb> that is a pretty tough call. I would say that it is a bug but I'd be willing to be argued away from that point of view. In some ways it sounds like a malformed patch file.
16:43 <grondo> To me it seems like a bug, but I could understand how patch is just handling a stream of "patches" and in that stream are really two separate patches. But like you said, it is common (though this is first I've seen it)
16:43 <neb> I can almost visualize the logic in patch that doesn't work. OTOH I can also imagine that trying to fix that logic would be a pain in the ass.
16:44 <grondo> BTW, the particular patch that was giving me grief was linux-2.6.9-x8664-core.patch
16:45 <grondo> Quilt uses --backup to save a copy of the original file before patching. It can then refresh the patch by rediffing against the original
16:45 <neb> I was just in the process of suggesting that you rediff the patch
16:46 <grondo> However, since the original it is diffing against is now a half-modified file, you lose half the patch and your refreshed patch now has conflicts
16:46 <grondo> Yeah, but I only just figured out the problem
16:46 <neb> I imagine the logic is something like
16:46 <neb> read filename
16:46 <neb> copy file to file.orig
16:46 <neb> apply patch
16:47 <neb> loop back to next file
16:47 <neb> ...
16:47 <grondo> all they would have to do is cache the filenames that have already been backed up
16:47 <neb> What is happening that you hit the same file twice and so it overwrites the orig file that it just wrote.
16:47 <grondo> Yes, that is definitely what is happening
16:48 <neb> I'd have to think about it more but I think the caching the filenames that were already modified by patch and not recreating orig files for them might work.
This event sent from IssueTracker by jplans  [Support Engineering Group]
 issue 113310

Action: Steps:
[ben@quince foo]$ vi file
[ben@quince foo]$ cat file
Original file
[ben@quince foo]$ cp file file.new
[ben@quince foo]$ vi file.new
[ben@quince foo]$ cat file.new
Original file
New line added
[ben@quince foo]$ diff -u file file.new > first.patch
[ben@quince foo]$ cp file.new file.newest
[ben@quince foo]$ vi file.newest
[ben@quince foo]$ cat file.newest
Original file
New line added
Another new line
[ben@quince foo]$ diff -u file.new file.newest > second.patch
[ben@quince foo]$ cat first.patch second.patch > combined.patch
[ben@quince foo]$ cat combined.patch
[ben@quince foo]$ cat first.patch second.patch
--- file        2007-02-09 11:53:00.000000000 -0800
+++ file.new    2007-02-09 11:53:42.000000000 -0800
@@ -1 +1,2 @@
 Original file
+New line added
--- file.new    2007-02-09 11:53:42.000000000 -0800
+++ file.newest 2007-02-09 11:55:04.000000000 -0800
@@ -1,2 +1,3 @@
 Original file
 New line added
+Another new line
[ben@quince foo]$ vi combined.patch
[ben@quince foo]$ cat combined.patch
--- file        2007-02-09 11:53:00.000000000 -0800
+++ file.new    2007-02-09 11:53:42.000000000 -0800
@@ -1 +1,2 @@
 Original file
+New line added
--- file        2007-02-09 11:53:42.000000000 -0800
+++ file.newest 2007-02-09 11:55:04.000000000 -0800
@@ -1,2 +1,3 @@
 Original file
 New line added
+Another new line
[ben@quince foo]$ cp file file.begin
[ben@quince foo]$ patch --backup < combined.patch
patching file file
patching file file
[ben@quince foo]$ cat file.orig
Original file
New line added
[ben@quince foo]$ cat file.begin
[ben@quince foo]$ cat file
Original file

So notice that the orig file represents the file after the first time that
file was patched not the original state of the file.


Issue escalated to Support Engineering Group by: kbaxley.
Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by jplans  [Support Engineering Group]
 issue 113310

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred.  You may
reopen this bugzilla for consideration in the next release.

This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release.  This request will
be reviewed for a future Red Hat Enterprise Linux release.

Proposing for RHEL-5.3 and granting Devel ACK.

Read ya, Phil

Created attachment 310414 [details]
patch-posix-backup.patch

Here is the patch I propose to add.  A version of this (rebased against the
alpha 2.5.9 version of patch) was sent to the upstream maintainer Paul Eggert
on June 16th.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0844.html