Bug 7265 – Backup/Restore Version Conflict dialog needs to be more verbose

Bug 7265 - (int-152020) Backup/Restore Version Conflict dialog needs to be more verbose

(int-152020)
Summary:	Backup/Restore Version Conflict dialog needs to be more verbose

Status:	NEW

Product:	Settings and Maintenance
Component:	Backup/Restore
Version:	5.0/(2.2009.51-1)
Platform:	All Maemo

Importance:	Low normal with 1 vote (vote)
Target Milestone:	---
Assigned To:	unassigned
QA Contact:	backup-restore-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-12-23 17:04 UTC by Tim Samoff
Modified:	2014-03-08 10:43 UTC (History)
CC List:	6 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description Tim Samoff (reporter) maemo.org

2009-12-23 17:04:48 UTC

SOFTWARE VERSION:
2.2009.51-1

EXACT STEPS LEADING TO PROBLEM: 
1. Perform full backup restore from previous version (2009.42-11)
2. Select all components to restore
3. Wait for Version Conflict dialog to appear (during Restore Settings segment)

EXPECTED OUTCOME:
Dialog explains exactly what is happening.

ACTUAL OUTCOME:
Dialog says:

"Device contains a file of the same name. Rename file from the backup to
prevent loss of data?"

The button choices are [Rename] and [No]
REPRODUCIBILITY:
Unknown at this time.

OTHER COMMENTS:
It would be nice to know exactly which file is being referred to.

Comment 1 Tim Samoff (reporter) maemo.org

2009-12-23 17:29:02 UTC

*** Bug 7266 has been marked as a duplicate of this bug. ***

Comment 2 Florian Boor 2009-12-24 23:57:35 UTC

I can confirm this behaviour but I see this as way more critical for two
reasons:
1. The message is extremely confusing for an average user since there is no way
to find out more about the conflict situation.
2. If files are affected that are usually not exposed to the user it is not
feasible to recover from this situation for an average user. Even if it is not
the case the default behaviour (renaming the file from the backup) could cause
the impression that some data was lost. This is extremely bad user experience
and should be avoided.

Raised the priority because a lot of people will run into this situation by
flashing the new software release.

Comment 3 Florian Boor 2009-12-30 22:42:37 UTC

It would be nice if you would add a comment why you change the priority of a
bug. Random changes do not get us closer to a solution. I think I gave a
reeasonable explanation why I think this bug should be processed with a high
priority.

Comment 4 Andre Klapper maemo.org

2009-12-30 23:37:56 UTC

Hi Florian, true...
Because developers set the priority, and this has not happened yet for this bug
report (neither here or nor internally). I prefer to keep "High" reserved for
issues that "really" (in a literal meaning) have a high priority.

Comment 5 Spencer Goh 2010-01-14 20:21:32 UTC

I just had this after restoring from backup after PR1.1
I had no way of finding out what the conflicted file was, nor do I know where
the copy / backup of that conflict is. Or even the filename format so I can
search for it. 

(I opted to take a copy of the file instead of replacing) not sure what effect
that now has on my system.