bugGNU patch - Bugs: bug #50969, patch fails on read-only files

 
 

bug #50969: patch fails on read-only files

Submitted by:  Philip Prindeville <pprindeville>
Submitted on:  Sun 07 May 2017 11:12:52 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 07 May 2017 11:31:59 PM UTC, comment #2:

Actually something like --read-only=warn but without the warnings...

Philip Prindeville <pprindeville>
Sun 07 May 2017 11:13:37 PM UTC, comment #1:

If everyone agrees this is the right course of action, I can bang out and test a fix in a couple of hours.

Philip Prindeville <pprindeville>
Sun 07 May 2017 11:12:52 PM UTC, original submission:

This might sound like an oxymoron but it's not. After all, you can 'vi' a file which is read-only and as long as you're the owner (or super-user), use 'w!' to rewrite it.

The idea is to provide a similar capability to 'patch', possibly via an optional flag which enables this normally suppressed capability.

The issue is that sometimes you run an automated build machinery (like 'buildroot') which downloads tarballs and patches them as part of the build process. Occasionally the authors of these tarballs bundle them as 0444 assuming that they are perfect as is and no one needs to patch them.

Well, in a perfect world...

But in some corner cases (often involving old compilers, ancient versions of autotools, or out-of-the-mainstream runtimes like uClibc or MUSL), things fail to build and need to be patched.

Not the end of the world.

So how to patch them?

Either patch needs to be able to save the original perm, chmod u+w the sources, change them, and then chmod them back to the original permissions... or else something uglier with more potential consequences needs to happen.

You could 'grep' out of your patch file all the file names which need to be changed, and for files which exist but don't have owner write permission, change that... That works fine for compiled sources, but has potential unintended consequences for script files which get install'd without any -m xxx flag (i.e. assuming that the original permissions haven't been modified and that they should be preserved across the copy into $DESTDIR...).

Not reliably always the case either.

So the best bet is to save the original perms, chmod them up temporarily to u+w, modify the file, and then chmod them back to the original modes.

This has no unintended consequences.

Philip Prindeville <pprindeville>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pprindeville (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1