Bug 321561

Summary: K3b does not respect user's input on overwrite dialog, always overwrites
Product: [Fedora] Fedora Reporter: Peter H. Jones <jones.peter>
Component: k3bAssignee: Harald Hoyer <harald>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 8CC: rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-12 13:06:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter H. Jones 2007-10-06 19:35:58 UTC 
Description of problem:
When K3b is creating an image from a DVD, duplicate image name is detected, but
writing is allowed, even if the user says "no" to the ensuing dialogue.

Version-Release number of selected component (if applicable):
k3b-1.0.3-3.fc8

How reproducible:
Always.

Steps to Reproduce:
1. Start K3b
2. Select Tools,Copy DVD
3. Set options to "Only Create Image", <existing file>, "Ignore errors"
4. A dialog requesting permission to overwrite the existing file appears
5. Select No
 
Actual results:
K3b copies over the existing file anyway.

Expected results:
K3b should return to main menu, or offer the user a chance to specify a new name

Additional info:

What I actually did was to copy to a new file, then repeat the copying with the
same parameters, just to reassure myself that I wouldn't accidentally overwrite
an existing DVD image.

Assigned priority as High because of the risk of data loss. May apply to all
platforms, did not test that.
Comment 1 Rex Dieter 2007-10-06 21:41:14 UTC 
imo, this is an ideal candidate to file upstream @ bugs.kde.org.
Comment 2 Peter H. Jones 2007-10-07 00:14:44 UTC 
Done. See
http://bugs.kde.org/show_bug.cgi?id=150551
Comment 3 Rex Dieter 2007-12-12 13:06:52 UTC 
Thanks, will (continue to) track this one upstream.