Bug 839292 - Teporary file is left behind with the sed option '--copy'
Teporary file is left behind with the sed option '--copy'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sed (Show other bugs)
6.3
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: Martin Bříza
qe-baseos-tools
:
Depends On: 832855
Blocks: 707622
  Show dependency treegraph
 
Reported: 2012-07-11 09:30 EDT by Mark Wu
Modified: 2012-07-14 15:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 832855
Environment:
Last Closed: 2012-07-12 06:49:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Wu 2012-07-11 09:30:42 EDT
+++ This bug was initially created as a clone of Bug #832855 +++

Description of problem:
We found the temporary file is left behind when the sed option '--copy' is used.
This problem happens when vdsm manipulate libvirt's configuration.  Vdsm has to use the option '--copy' since the system call 'rename' is not allowed on bind-mount files (on ovirt node). I can't see the point of remaining the temporary file. My understanding is that with and without '--copy' should be just different ways(truncate+cp vs rename) to change the file in pace. So I think the temporary file should be removed after done.


Version-Release number of selected component (if applicable):
sed-4.2.1-8.fc17

How reproducible:
everytime

Steps to Reproduce:
sed -i --copy -e 's/todo/done/' my_todo_list
then a temporary file like 'sedcMkUCu' was remained after the operation done.

Actual results:


Expected results:
No temporary file is removed after done.

Additional info:

--- Additional comment from mbriza@redhat.com on 2012-06-18 16:38:51 CST ---

Hello Mark,

thanks for reporting. I can confirm this bug to be present in Fedora 16. I will have a look at as soon as possible.

--- Additional comment from mbriza@redhat.com on 2012-07-09 20:58:29 CST ---

Created attachment 597071 [details]
Proposed patch to fix the issue

This patch should fix the issue when applied to the fedpkg repository. I'll build testing packages for you tomorrow.
There was a problem with the ported patch - it wasn't ported entirely and the ck_fcopy function was left behind.

--- Additional comment from mbriza@redhat.com on 2012-07-10 22:28:42 CST ---

Created attachment 597355 [details]
Proposed patch to fix the issue (changed function names)

Hello,
I changed the patch a little bit more to reflect what the functions ck_fcmove and ck_fccopy do. I built a package with this patch on
http://koji.fedoraproject.org/koji/taskinfo?taskID=4230648
so you can test it if you want to.
Thank you.

--- Additional comment from wudxw@linux.vnet.ibm.com on 2012-07-11 07:31:45 CST ---

Martin,

Thanks for the test package. It fixes the problem I reported here.
Comment 2 Martin Bříza 2012-07-12 03:35:03 EDT
I just tried to reproduce this in RHEL 6.3 and there are no files left behind. Does that happen to you, Mark?
Comment 3 Dan Kenigsberg 2012-07-12 05:06:26 EDT
Hmm, indeed it does not show up with sed-4.2.1-10.el6.x86_64

Martin, any idea how come this is different from the Fedora (/upstream) behavior?
Comment 4 Martin Bříza 2012-07-12 06:49:19 EDT
The difference from upstream is simple - the "--copy" parameter was (re)added by us, upstream doesn't have it at all.
I took a quick look into the repository and I see the bug was already fixed in RHEL 6 based on #709956 report. Other distributions, however, were left with the wrong patch that was, I think, ported on rebase to sed 4.2.1 (in RHEL 5 the parameter is all right and that's the place where I took the code for my patch) but didn't apply correctly.

I think I can close this report now, reports for affected distributions and versions are already opened so there is nothing else to do. Of course, if it indeed does affect you, feel free to reopen the bug.

Thanks for reporting.
Comment 5 Dan Kenigsberg 2012-07-14 15:30:33 EDT
Martin, thanks for researching the issue.
Mark, thanks indeed for your report.

Note You need to log in before you can comment on or make changes to this bug.