Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionMiroslav Vadkerti
2010-08-02 12:48:02 UTC
Description of problem:
sed overwrites symlinks and creates ordinary file instead. This is a Regression of bz#189016.
Version-Release number of selected component (if applicable):
sed-4.2.1-5.el6
How reproducible:
100%
Steps to Reproduce:
1. touch src
2. ln -s src lnk
3. sed -i 's.o.n.g' lnk
Actual results:
lnk is overwritten
Expected results:
lnk not overwritten
Additional info:
This change was done in Fedora 11 and is by design.
RHEL 3 included this change without even looking at the manual or contacting upstream. In doing so it deviated unnecessarily from what is documented in its own "info sed", from upstream, from basically all other Linux distros, and also from "perl -i" behavior.
The implementation was also bad, since there are bugs in symlink following in RHEL5 -- bug #490473 -- while realpath(3) could have been used much more simply...
RHEL6 sed provides --follow-symlinks which achieves this behavior.
I suggest documenting it in the release notes.
From the sed manual of RHEL6
`-i' clobbers read-only files
In short, `sed -i' will let you delete the contents of a read-only
file, and in general the `-i' option (*note Invocation: Invoking
sed.) lets you clobber protected files. This is not a bug, but
rather a consequence of how the Unix filesystem works.
The permissions on a file say what can happen to the data in that
file, while the permissions on a directory say what can happen to
the list of files in that directory. `sed -i' will not ever open
for writing a file that is already on disk. Rather, it will work
on a temporary file that is finally renamed to the original name:
if you rename or delete files, you're actually modifying the
contents of the directory, so the operation depends on the
permissions of the directory, not of the file. For this same
reason, `sed' does not let you use `-i' on a writeable file in a
read-only directory, and will break hard or symbolic links when
`-i' is used on such a file.
Everything except "and will break hard or symbolic links when `-i' is used on such a file" is present also in RHEL5 (however it could be inferred from the description, which says it is renaming a temporary file to the original name).