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:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned 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 01 Sep 2019 05:27:55 PM UTC, comment #3: 

I would think that in a situation where a file is found to be read-only, it indicates one of two things: 1. The file should not be modified. Or 2. There is something wrong with the patch/build environment.

I think trying to automate editing a file that is specifically set to read-only would be considered bad behaviour by Patch.

A better solution, in my mind, is instead of modifying Patch to possibly edit read-only files would be to have the patch/build environment run chmod after unpacking the source tarball. That seems like a more modular, Unix-y way to deal with things.

That way permissions are handled by one tool and patching is handled by another tool. That feels more elegant than hacking a permission tool into Patch. Is there any reason a build environment cannot run "chmod -R -u+w *"?

Jesse <newguy>
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 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 newguy (Posted a comment)
  • -email is unavailable- added by pprindeville (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.5