bugGNU patch - Bugs: bug #44251, doesn't follow symlink directories

 
 

bug #44251: doesn't follow symlink directories

Submitter:  Laszlo Boszormenyi (GCS) <gcs>
Submitted:  Sat 14 Feb 2015 06:52:15 PM UTC
   
 
Category:  None Severity:  1 - Wish
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 Sep 2015 08:05:21 PM UTC, comment #12: 

I see possible duplicates with bug #45581 and #44905

Fabio <efferre79>
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

Fabio <efferre79>
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.

Jean Delvare <khali>
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 .

Laszlo Boszormenyi (GCS) <gcs>
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.

Andreas Gruenbacher <agruen>
Group administrator
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.

Andreas Gruenbacher <agruen>
Group administrator
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.

Jean Delvare <khali>
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.

Andreas Gruenbacher <agruen>
Group administrator
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.

Jean Delvare <khali>
Sat 14 Feb 2015 08:11:13 PM UTC, comment #3: 

I see, thanks.

Andreas Gruenbacher <agruen>
Group administrator
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

Laszlo Boszormenyi (GCS) <gcs>
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.

Andreas Gruenbacher <agruen>
Group administrator
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

Laszlo Boszormenyi (GCS) <gcs>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by efferre79 (Posted a comment)
  • -email is unavailable- added by efferre79
  • -email is unavailable- added by khali (Posted a comment)
  • -email is unavailable- added by agruen (Posted a comment)
  • -email is unavailable- added by gcs (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-21 efferre79 Carbon-Copy- Added efferre79
    2015-03-07 agruen StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2015-02-14 agruen Severity3 - Normal 1 - Wish
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code