Mon 21 Sep 2015 08:05:21 PM UTC, comment #12:
I see possible duplicates with bug #45581 and #44905
|
Mon 21 Sep 2015 07:59:14 PM UTC, comment #11:
I'm using GNU patch 2.7.5 but something is still wrong
Here is a simple testcase:
~/testcase $ tree
.
├── a
│ └── file.txt
└── wd
├── a -> ../a
└── patch.diff
The patch.diff contents is
--- a/file.txt 2015-09-21 21:34:13.000000000 +0200
+++ a/file.txt.new 2015-09-21 21:33:22.000000000 +0200
@@ -1 +1 @@
-aaa
+bbb
I get this failure:
~/testcase/wd $ patch --debug 32 -p0 < patch.diff
Resolving path "a/" (failed)
Resolving path "a/" (failed)
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/file.txt 2015-09-21 21:34:13.000000000 +0200
|+++ a/file.txt.new 2015-09-21 21:33:22.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
|
Sat 07 Mar 2015 09:29:49 AM UTC, comment #10:
I tested 2.7.5 successfully too. I'll keep testing and I'll report if I notice any issue.
Thanks Andreas for the hard work, this is very appreciated.
|
Sat 07 Mar 2015 07:12:44 AM UTC, comment #9:
Indeed, the fix are correct. Tested in three ways, all worked now while was failing with 2.7.4 .
|
Sat 07 Mar 2015 12:44:34 AM UTC, comment #8:
Could you please see if patch-2.7.5 works as expected now? Thanks.
|
Mon 02 Mar 2015 09:37:03 PM UTC, comment #7:
> I don't know the code at all, but let me know if I can help with testing or something else.
Well, try to break the code on the testing branch by using weird combinations of symlinks (nested, recursive, etc.) that the test cases in the repo don't cover, exercise the directory lookup cache extremely, shrink the cache by setting "ulimit -n" to a small number, things like that.
|
Mon 02 Mar 2015 06:09:04 PM UTC, comment #6:
I'm very happy to see you're already working on it. And I didn't expect it to be easy :-/
I don't know the code at all, but let me know if I can help with testing or something else.
|
Mon 02 Mar 2015 03:52:20 PM UTC, comment #5:
See the testing branch in git. It's quite hard to get this right.
|
Mon 02 Mar 2015 02:14:36 PM UTC, comment #4:
The same problem affects the openSUSE project. Packages rpm and reportedly texlive-specs no longer build after moving to GNU patch version 2.7.4. There may be more.
Sure, it is certainly possible to rework the way patches are applied to these packages in openSUSE Factory to avoid patching through symlinks.
The problem is that GNU patch version 2.7.4 is also required for older distributions as it fixes security vulnerabilities. But if we simply push version 2.7.4 to our update channels, then the same breakage will happen with at least rpm, so we will have to patch it there too, and possibly some other packages as well (not necessarily the same ones as in Factory.)
Furthermore, we have no idea how users (or, in the SLE case, customers) are using GNU patch. It is entirely possible that this change in behaviour breaks their own processes. Having to update our own packaging code across many distributions would be painful but doable. However, pushing functional regressions to the users as part of a maintenance update is simply not acceptable.
I'm sure other distributions are equally affected. So I strongly believe that GNU patch should be updated to support patching through symbolic links again, as long as the link points inside the working directory.
|
Sat 14 Feb 2015 08:11:13 PM UTC, comment #3:
I see, thanks.
|
Sat 14 Feb 2015 07:24:22 PM UTC, comment #2:
I didn't tried it, but it was working in the past (with 2.7.1 I guess). Now at least one of Debian packages (nvidia-graphics-drivers) fails to build with the latest patch Git snapshot. Relevant part:
ln -s NVIDIA-Linux-amd64 NVIDIA-Linux
QUILT_PATCHES=debian/patches QUILT_SERIES=series-postunpack quilt --quiltrc /dev/null push -a || test $? = 2
Applying patch man-fixes-nvidia-smi.patch
file NVIDIA-Linux is not a directory
27 out of 27 hunks ignored
|
Sat 14 Feb 2015 07:05:10 PM UTC, comment #1:
Well, the whole point is not to follow symlinks to directories, the --follow-symlinks option only allows the last pathname component to be a symlink to a file to patch though.
Is there any need to ever follow symlinks to directories? That could be implemented, but we would still have to make sure we stay inside the working directory.
|
Sat 14 Feb 2015 06:52:15 PM UTC, original submission:
Test case (tried with --follow-symlinks as well):
mkdir -p a/link b/link
echo hello > a/link/file
echo world > b/link/file
diff -u a/link/file b/link/file > the.patch
rm -f a/link/file b/link/file
rmdir a/link b/link a b
mkdir dir
ln -s dir link
echo hello > dir/file
$ cat link/file
hello
$ patch -p1 --debug 32 < the.patch
Resolving path "link/" (failed)
Refusing to follow symbolic link link
$ patch -p1 --follow-symlinks --debug 32 < the.patch
Resolving path "link/" (failed)
Refusing to follow symbolic link link
|