Bug 839292

Summary: Teporary file is left behind with the sed option '--copy'
Product: Red Hat Enterprise Linux 6 Reporter: Mark Wu <wudxw>
Component: sedAssignee: Martin Bříza <mbriza>
Status: CLOSED CURRENTRELEASE QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.3CC: danken, mbriza, pbonzini
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 832855 Environment:
Last Closed: 2012-07-12 10:49:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 832855    
Bug Blocks: 707622    

Description Mark Wu 2012-07-11 13:30:42 UTC
+++ 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 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 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 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.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 07:35:03 UTC
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 09:06:26 UTC
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 10:49:19 UTC
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 19:30:33 UTC
Martin, thanks for researching the issue.
Mark, thanks indeed for your report.