This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 494080

Summary: patch always implies -b (--backup) option and creates *.orig files
Product: [Fedora] Fedora Reporter: linux
Component: patchAssignee: Tim Waugh <twaugh>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: artem.zolochevskiy, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-06 11:46:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description linux 2009-04-03 22:00:45 EDT
User-Agent:       Mozilla/5.0 (U; en-US) Gecko Firefox

if I use "bzip2 -dc patch.bz2 | patch -p1" or any other way I use patch it always uses the -b option and creates *.orig files.
This breaks for example the build process with rpmbuild as diff's from a dir where I have used the command above to patch something include the *.orig files. Applying the first part of a given .patch file by rpmbuild also creates a *.orig file and as the diff also included a new *.orig file an error is displayed and rpmbuild fails.

Reproducible: Always

Steps to Reproduce:
1. patch some file in some dir (not using the -b option from patch)
2. list dir, observe if "file.orig"-file is present
Actual Results:  
"file.orig"-file is present

Expected Results:  
"file.orig"-file is not present
Comment 1 linux 2009-04-04 09:24:15 EDT
packet version is:
patch-2.5.4-35.fc10 (i386)
Comment 2 Tim Waugh 2009-04-06 11:46:56 EDT
I can't reproduce this.  Here's the test I tried:

echo b > a
echo a > a.orig
diff -u a.orig a > a.patch
rm -f a.orig
echo a > a
patch a -i a.patch
ls
Comment 3 linux 2009-04-06 12:46:43 EDT
inside kernel-source (from current kernel-package)

ls arch/x86/kernel/cpu/cpufreq/ | grep acpi

Output: acpi-cpufreq.c

bzip2 -dc ../../patches/linux-phc-0.3.2-kernel-vanilla-2.6.26.patch.bz2 | patch -p1

Output: patching file arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
Output: Hunk #4 succeeded at 751 (offset 1 line).

ls arch/x86/kernel/cpu/cpufreq/ | grep acpi

Output: acpi-cpufreq.c
Output: acpi-cpufreq.c.orig

You are right, 'always' in an overstatement, but maybe some patches with offsets?
There seems no way of disabling the .orig-file creation (which I am aware of), so I manually have to remove it. Worked with Fedora 10 without any updates.

kernel-2.6.27.21-170.2.56.fc10.src.rpm
Patch from http://www.linux-phc.org/
Comment 4 linux 2009-04-06 12:56:01 EDT
Even a new patch with no offset creates the same thing.

ls arch/x86/kernel/cpu/cpufreq/ | grep acpi

Output: acpi-cpufreq.c

cat ../../patches/linux-2.6-phc.patch | patch -p1

Output: patching file arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c

ls arch/x86/kernel/cpu/cpufreq/ | grep acpi

Output: acpi-cpufreq.c
Output: acpi-cpufreq.c.orig

using

patch -p1 <../../patches/linux-2.6-phc.patch

works as expected. Maybe my syntax is wrong...
Comment 5 Tim Waugh 2009-04-06 13:01:36 EDT
Rather than using one of the largest RPM packages in the distribution, please try to construct a small test case that demonstrates the problem you are seeing.
Comment 6 linux 2009-04-06 13:50:22 EDT
I am sorry. The described way is the one where I noticed it at first.

It must be some problem only invoked by all patches I tried and derivatives of them, as I can't create any test case which is 'small' from scratch.

What ever is causing this drives me crazy. I'am going to create a script which removes all the *.orig files and don't bother you anymore until I can come up with a simple test case.
Comment 7 Artem Zolochevskiy 2009-05-05 15:20:41 EDT
(In reply to comment #6)
> I am sorry. The described way is the one where I noticed it at first.
> 
> It must be some problem only invoked by all patches I tried and derivatives of
> them, as I can't create any test case which is 'small' from scratch.

Incomplete Lines?
(http://www.network-theory.co.uk/docs/diff/Incomplete_Lines.html)

I can reproduce this:

$ echo -e "firstline\nsecondline" > a
$ echo -e "firstline\nsecondline\nthirdline" > b
$ diff -u a b > ab.patch
$ ls
a  ab.patch  b
$ echo -en "firstline\nsecondline" > a1
$ patch a1 -i ab.patch
$ ls
a  a1  a1.orig  ab.patch  b
Comment 8 linux 2009-05-06 08:37:56 EDT
That is correct and I am now able to fix the affected patches. Thank you.

In my opinion patch shouldn't leave the *.orig file, even if the patch doesn't end with a new line, as long as it applies without errors.
Comment 9 Tim Waugh 2009-05-06 10:09:51 EDT
This is a case of the context not matching.  Use the --no-backup-if-mismatch option if you don't want this POSIX behaviour.