Hide Forgot
=> What is the nature and description of the request? ---------------------------------------------------- The patch utility currently does not back up the original file by default whenever it is patched. The file is backed up only when the patch fails. This is correct behaviour according to POSIX, but has not been this way traditionally. Traditional Unix systems (BSD) back up the original file by default. Customer would like to have this behaviour ported to the GNU version of patch, i.e. the patch that we ship. => Why does the customer need this? ---------------------------------- 1) You may need to exec() patch directly or call it using its absolute path, making aliases redundant 2) Users may be using alternative shells, which may not source /etc/profile => How would the customer like to achieve this? ---------------------------------------------- Modify the patch utility such that it backs up the original file every time it tries to patch a file, regardless of whether the patch succeeds or fails => For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. ---------------------------------------------------------------------------- This can be tested easily locally by checking if a .orig file is created for every invocation of patch. => Is there already an existing RFE upstream or in Red Hat bugzilla? -------------------------------------------------------------------- No => How quickly does this need resolved? (desired target release) ---------------------------------------------------------------- Update to RHEL-5 => Does this request meet the RHEL Inclusion criteria (please review) --------------------------------------------------------------------- I am not sure, since I am not sure how to categorize this. The change itself is fairly easy to make. The impact however could be large since this is essentially a big change in behaviour that should be documented and customers made aware of it in advance. Based on the latter, I am inclined to think that it does not meet the inclusion criteria. => List the affected packages ----------------------------- patch => Would the customer be able to assist in testing this functionality if implemented? ---------------------------------------------------------------------------- This is not necessary since we can test this ourselves.
I'm not clear why this change is required: the given reasons show why it is not sufficient to have an alias, but don't address the actual reason for the proposed change. Changing GNU patch's backup file behaviour would be a very significant change indeed. Backup files being generated unexpectedly have been known to break package builds, for example. At the very least, the affected packages would include "rpm"... Additionally, the behaviour of GNU patch regarding backup files is well documented and so it is a reasonable expectation that many customers require it to work the way it currently does.
The customer's original motivation was not captured when the template was used. In the support case's original description, the customer's motiviation is "Erroneous uses of patch results in lost files. Recovering lost files is slow and expensive. Backups avoid the lossage."
If a patch is applied mistakenly, it can be unapplied using 'patch -R', restoring the original file contents.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Thank you for submitting this issue for consideration. Red Hat Enterprise Linux 5 has reached the end of Production 1 Phase of its Life Cycle. Red Hat does not plan to incorporate the suggested capability in a future Red Hat Enterprise Linux 5 minor release. If you would like Red Hat to re-consider this feature request and the requested functionality is not currently in Red Hat Enterprise Linux 6, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.