Bug 494080
| Summary: | patch always implies -b (--backup) option and creates *.orig files | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | linux |
| Component: | patch | Assignee: | Tim Waugh <twaugh> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | 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 15:46:56 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
linux
2009-04-04 02:00:45 UTC
packet version is: patch-2.5.4-35.fc10 (i386) 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 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/ 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... 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. 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. (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 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. This is a case of the context not matching. Use the --no-backup-if-mismatch option if you don't want this POSIX behaviour. |