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

 
 

bug #50969: patch fails on read-only files

Submitter:  Philip Prindeville <pprindeville>
Submitted:  Sun 07 May 2017 11:12:52 PM UTC
   
 
Category:  None Severity:  3 - Normal
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

Thu 01 May 2025 11:49:33 AM UTC, comment #7: 

Applied (after a little bit of description massaging). Thank you.

Andreas Gruenbacher <agruen>
Group administrator
Thu 01 May 2025 05:06:05 AM UTC, comment #6: 

thanks for the simplification. Patch attached (couldn't find my gmail setting to allow git-send-email to work).

Daniel Black <danielgblack>
Wed 30 Apr 2025 01:52:25 PM UTC, comment #5: 

I agree that patch shouldn't warn about read-only input files when an output file has been specified.

A simpler command to reproduce is this:

patch -o - /etc/passwd /dev/null > /dev/null


Andreas Gruenbacher <agruen>
Group administrator
Wed 30 Apr 2025 06:01:43 AM UTC, comment #4: 

$ patch -r - -f -s -o /tmp/p.out /etc/passwd p.p
File /etc/passwd is read-only; trying to patch anyway

A more straight forward case to this is if you've specified an output file there's no need to warn that the input is read-only.

Anonymous
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:
   

Attached Files
file #57184:  0001-When-output-specified-ignore-read-only-input.patch added by danielgblack (1KiB - text/x-patch - Attach is patch removing warning if output specified)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by danielgblack (Updated the item)
  • -email is unavailable- added by agruen (Posted a comment)
  • -email is unavailable- added by newguy (Posted a comment)
  • -email is unavailable- added by pprindeville (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-05-01 agruen StatusNone Fixed
        Open/ClosedOpen Closed
    2025-05-01 danielgblack Attached File- Added 0001-When-output-specified-ignore-read-only-input.patch, #57184

    Back to the top

    Powered by Savane 3.15-f85b.
    Corresponding source code