After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 47893 - The ``Replace File'' dialog should display the two file sizes, times, etc.
The ``Replace File'' dialog should display the two file sizes, times, etc.
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: 3.0
Assigned To: Cosimo Cecchi
Nautilus Maintainers
: 60799 121457 145080 163865 308290 335352 338737 400129 447220 530726 585321 637433 (view as bug list)
Depends on:
Blocks: 346324
 
 
Reported: 2001-03-26 23:45 UTC by Ben FrantzDale
Modified: 2010-12-17 15:48 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Test file dialog box (19.80 KB, image/png)
2005-05-05 21:18 UTC, Corey Burger
Details
Dialog box (44.34 KB, image/png)
2005-06-19 19:01 UTC, Joachim Noreiko
Details
Dialog box mk3 - default unexpanded view (18.15 KB, image/png)
2005-06-21 10:50 UTC, Joachim Noreiko
Details
nautilus merge replace dialog (null) when copying folders (37.70 KB, image/png)
2010-03-14 22:33 UTC, Eduardo Pérez Ureta
Details

Description Ben FrantzDale 2001-09-10 01:31:35 UTC
At the moment the warning dialog for overwriting a file says:
---------------------------------
Conflict... copying
File "/path/to/file/foo"
already exists.

Would you like to replace it?
[Replace]    [Skip]
--------------------------------

This is not very informative. The dialog could, like the windows version of it,
display the size of the two files, their date stamps, etc. (If there's a viewer
for the two files it could even show the two side by side.) Beyond that, I would
suggest that if the two files are exactly the same size and have the same
properties, nautilus could diff the two and let the user know if the files are
identical (or if not and they are plain text where they differ.)



------- Additional Comments From darin@bentspoon.com 2001-03-26 19:19:59 ----

I also really like how Mac OS tells you which of the files is newer.



------- Additional Comments From arlo@workthatmouse.com 2001-04-10 01:34:18 ----

I agree... assigning to Pavel to consider implimentation details.



------- Additional Comments From snickell@stanford.edu 2001-07-23 00:34:02 ----

Taking bugs previously assigned to Pavel, assigning them to myself. Will parse
them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0



------- Additional Comments From mjs@noisehavoc.org 2001-07-23 01:16:18 ----

Move to unassigned. I'll probably want to take a crack at some of these myself,
and Seth says he is unlikely to.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:31 -------
Comment 1 John Fleck 2002-01-05 04:09:22 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 John Fleck 2002-01-26 04:16:09 UTC
Adding GNOME2 keyword.
Comment 3 Luis Villa 2002-02-28 14:22:30 UTC
This would be nice. Marking 'high' enhancement. [John, FWIW, the
'mustfix' script I sent you last night ignores high enhancements like
this one. Or it should; please let me know if it doesn't.]
Comment 4 Dave Bordoley [Not Reading Bug Mail] 2002-05-16 05:19:26 UTC
*** Bug 60799 has been marked as a duplicate of this bug. ***
Comment 5 John Fleck 2003-04-26 20:12:52 UTC
Marking priority down to "normal", based on the lack of attention and
interest this bug has drawn, and the fact that we're trying to really
use "priority->hight" now.
Comment 6 Mark Finlay 2003-09-18 09:48:06 UTC
*** Bug 121457 has been marked as a duplicate of this bug. ***
Comment 7 Christian Neumair 2004-10-20 19:50:30 UTC
*** Bug 145080 has been marked as a duplicate of this bug. ***
Comment 8 Uri David Akavia 2005-02-15 08:15:40 UTC
Has anyone noticed that this 4 year old bug (!) is a "dataloss" bug, under
certain circumstances?
I request that the priority be upped, because of the dataloss option (especially
when combined with spatial).
I understood (from a comment on a mailing list) that the problem is the UI - in
that case, how about just copying Mac OSX or MS Windows, and fixing it later?
Comment 9 Corey Burger 2005-05-05 21:18:18 UTC
I am attaching an ugly as sin dialog for doing this. Maybe we can get someone to
do within the 2.12 cycle.
Comment 10 Corey Burger 2005-05-05 21:18:47 UTC
Created attachment 46071 [details]
Test file dialog box
Comment 11 Corey Burger 2005-05-05 21:20:21 UTC
Before anyone comments, the following needs to be fixed:
1. change the arrow to the default forward one in gnome. I couldn't select it
for some reason
2. Tie the 2 locations and arrow together visually
3. Make the top text bigger
4. Center the file name and icon
Comment 12 Olav Vitters 2005-05-06 21:47:02 UTC
*** Bug 163865 has been marked as a duplicate of this bug. ***
Comment 13 Olav Vitters 2005-06-19 13:08:28 UTC
*** Bug 308290 has been marked as a duplicate of this bug. ***
Comment 14 Joachim Noreiko 2005-06-19 19:01:41 UTC
Created attachment 48014 [details]
Dialog box

I'm attaching my attempt made in Glade. (The arrow problem is Bug 167933, btw.)


Some explanations:
* I've followed the instructions in the HIG, but the markup isn't working at
the top
* Nautilus should quickly compare properties, starting with modification date,
and then size if the dates are the same, and finally a diff, and set the dialog
text accordingly: older / newer / smaller / larger / identical.
* If the user makes changes in the filename text boxes, the "Replace" button
should change to read "Copy and Rename" or "Move and Rename".
* The "Compare file contents" expander should provide a diff for text files,
and a preview for images.
Comment 15 Corey Burger 2005-06-20 16:34:05 UTC
Hmm, I think your dialog is too wordy. We need something fast. 

That being said, another sentence on mine might not be a bad idea.

Thoughts?
Comment 16 Joachim Noreiko 2005-06-20 17:16:51 UTC
How about:

Top text: "A [newer|older|etc] file name "foo.txt" already exists in the folder
"bar"". (Which drops the awkward "destination".)

Text in properties expander: "Click on the filenames to rename files."
Though that could actually just be a tooltip. Renaming files within this dialog
is what I would call a power user feature, and I think it's ok for these to not
be explained in so much detail. An advanced user would spot that the names are
in editable boxes, and make the correct assumption.

I'm not so sure any more about my idea of a "rename" button replacing "replace".
It means the user can't change their mind about renaming, unless they
laboriously retype the original filenames (assuming they can remember them). But
if the "rename" button appears to the left of "skip" as a 3rd option (once the
user has altered the filenames), then does that mean the action performed by
"replace" is now ambiguous?
Comment 17 Corey Burger 2005-06-20 17:26:45 UTC
Hmm, I think we need to keep this as simple as possible. There should be 2
options (replace and skip).

Possibly add a rename file button, so rename the file incoming file.
Comment 18 Joachim Noreiko 2005-06-21 10:50:03 UTC
Created attachment 48083 [details]
Dialog box mk3 - default unexpanded view

Default, unexpanded view of the dialog box.
I've made the text more concise.
Comment 19 Corey Burger 2005-06-21 18:14:37 UTC
Why is that better? Now the person has to click. I can't think of a use case
where the person doesn't want to the see the properties.
Comment 20 Joachim Noreiko 2005-06-22 12:41:32 UTC
I'm thinking along the same lines as the "Save" dialog. That's quite minimal in
its default state -- you just get to choose the filename, and the location from
a drop-down that has your home and favourite folders. To pick another location
you need to expand for more data. I nearly always expand it -- there's a good
case IMO for GNOME to remember that I like it expanded and I might file that as
an enhancement -- but for the average user it's enough, and for novices it's
great because it avoids information overload.

For this dialog, I think that in most cases, the information in the text that
says "newer" or "older" is enough to base a decision on.

One advanced feature I'd like to see is for the case when I ask to move a file,
and it turns out that the file at the destination is newer. I'd like to be able
to say "Just delete the file I was trying to move" -- sort of the opposite of
the "Replace" option. But I don't see how that could be presented intuitively in
the GUI, and it's rather a complicated concept to explain.
Comment 21 Corey Burger 2005-06-22 20:54:15 UTC
A couple of points:
-I can't think of a use case where the user doesn't want to see some differences
between the files.
-Your dialog is almost the same on first glance
-Mac OS X and Windows do it the way I suggested, and it seems to work for them

Comment 22 Luis Villa 2005-07-10 05:09:16 UTC
You guys might want to move this discussion to nautilus-list for wider feedback.
Comment 23 Uri David Akavia 2005-07-18 10:00:33 UTC
I don't see a need to have a "Rename" button, textbox, or for that matter, anything.
If a user wants to rename, he can quit the dialog, rename the files and copy
again (maybe he wants to rename the destination file, maybe he wants to rename
the original file).
Pushing too much functions into the same dailog is a BAD idea. This dialog
should simply tell you that a file with the same name exists, and give you
enough detail (date modified, size, and perhaps date created) to decide if you
want to overwrite or not. That's it.
Comment 24 Calum Benson 2005-07-18 14:46:02 UTC
I agree we don't want to go overboard here, but one advantage of providing a way
to handle the situation in the dialog is that the selection of files the user is
dragging/pasting may be quite complex, and they will lose it if they have to go
back to the file manager and rename one of the source files*.  (And losing
complicated selections through no fault of my own is certainly something that
annoys me a lot, as a user.)

Also, if they had to go back and rename a file themselves, wouldn't they then
also have to remember which files had already been successfully copied, to avoid
another bunch of 'this file already exists' warnings when they tried to repeat
the operation?

* You could argue this one is partly a bug against nautilus, in that it doesn't
let you rename a file without altering the existing selection, and there's no
reason why it shouldn't, really.  But I doubt you could fix this in such a way
that you'd prevent most users from selecting it first anyway.
Comment 25 Joachim Noreiko 2005-07-18 19:51:31 UTC
An extra dialog action button to cancel the entire operation would be useful.

Example:

The user has selected a large number of files to copy or move.
There is a conflict on the first one, and this makes the user realize that he
has moved/copied to the wrong folder! "Cancel Move"/"Cancel Copy" should stop
the action and revert(*) what's been done so far.

(*) Would it be a good idea to verify for duplicates before any actual file
manipulations are made? This would avoid the tedious situation of having to
babysit a VERY large operation, because you'd get all the user input out of the
way and then leave it to work.
Comment 26 Uri David Akavia 2006-01-24 09:02:33 UTC
Can we get something - an ugly something even? It seems that this bug isn't moving because people are debating on how to get it perfect.
I might be wrong, but I feel that an ugly looking dialog, that alerts the viewer to the differences between the files is sufficient. It can be beautified later.
Comment 27 Joachim Noreiko 2006-01-24 13:52:46 UTC
Yes, I'm thinking the same thing.
Let's get the basics into this dialog and worry about making it perfect later.
Comment 28 megamania 2006-02-28 18:35:03 UTC
I agree with the people saying that this is a potentially "dataloss" bug, and a simple, no-frills solution would be very appreciated. 

The "Test file dialog box" looks excellent and effective - I'd just add that in my opinion the actual creation date/time should always be displayed (in the sample png, "yesterday" and "today" are used).

Since this is my first contribution to bugzilla, I take the opportunity to thank all the programmers for their efforts!
Comment 29 Benjamín Valero Espinosa 2006-09-11 11:05:22 UTC
Please, don't beat for this comment! I think Konqueror solves quite well this "bug". Anyway, let's fight with Glade. With a little of luck, this will appear in Gnome 3.0 :P
Comment 30 Christian Neumair 2006-12-26 18:29:32 UTC
Mass reassigning bugs with 2.2.0 milestone to 2.2.x milestone

Grep for "Mass reassigning" to filter out this bug spam.
Comment 31 Teppo Turtiainen 2007-01-21 19:05:39 UTC
*** Bug 338737 has been marked as a duplicate of this bug. ***
Comment 32 kenden 2007-02-26 15:01:35 UTC
To keep this report alive, an extract from: 
http://beranger.org/index.php?fullarticle=2484

"Here's where GNOME has a bad approach: when comes about overriding files.

1. Copy and paste some files over themselves, in the same directory: Nautilus creates duplicate files with "(copy)" appended to the name (actually, this is like in XP), while Konqueror asks me for the new filename:

2. Copy and paste some files in another directory, when files with the same name exist: Nautilus asks me something, but I can't tell which is the difference between the files, I can't even tell which one is newer!"

The URL shows screenshots of the KDE overwrite popup dialog, which seems quite sensitive.
Comment 33 Uri David Akavia 2007-04-13 09:45:57 UTC
A Six year old Dataloss bug has no action.
How about changing the priority to a higher one? If you're never going to fix this bug, just say so.

I'll repeat my suggestion - get an UGLY dialog to give data about the file, and then people will have motivation to fix it. Windows gives you this information. OSX gives you this information. KDE gives you this information. Why can't Nautilus give me this information??
Comment 34 Nickolay V. Shmyrev 2007-04-14 07:20:41 UTC
Uri, do you want to create a patch? I can probably help with it, so this problem will be solved easily.
Comment 35 Uri David Akavia 2007-05-04 16:05:14 UTC
I can't create a patch right now, since I'm drowning in academic work for the short term, and I'm not a programmer. However, if you can I will be very grateful.

I might take you up on that offer in a few months.

Thank you.
Comment 36 Susana 2007-08-08 01:41:52 UTC
*** Bug 447220 has been marked as a duplicate of this bug. ***
Comment 37 Uri David Akavia 2007-08-23 16:42:05 UTC
I won't have time to create a patch in the near future.
If Nickolay or anyone else feels like creating a patch, I would be grateful.

The other alternative is to close this 6 year old, dataloss bug as WONTFIX and be done with it.
Comment 38 Jérôme Guelfucci 2007-09-02 10:09:04 UTC
Same wish on Launchpad : https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/136702

Similar bug on gnome bug tracker : http://bugzilla.gnome.org/show_bug.cgi?id=400129
Comment 39 Uri David Akavia 2007-09-02 14:48:18 UTC
*** Bug 400129 has been marked as a duplicate of this bug. ***
Comment 40 Cosimo Cecchi 2008-02-18 16:05:40 UTC
*** Bug 335352 has been marked as a duplicate of this bug. ***
Comment 41 Cosimo Cecchi 2008-04-04 13:27:01 UTC
I have made a patch for this, I think it will be reviewed/merged for 2.24.
Comment 42 Cosimo Cecchi 2008-04-30 12:39:47 UTC
*** Bug 530726 has been marked as a duplicate of this bug. ***
Comment 43 Nicolò Chieffo 2008-04-30 13:00:53 UTC
Does the patch also simplify the "overwrite all", "skip all" buttons with an "apply to all" checkbox, or should I file another bug?
Comment 44 A. Walton 2008-04-30 13:03:23 UTC
http://mail.gnome.org/archives/nautilus-list/2008-April/msg00065.html 
For relevant discussion on this. The appropriate answer for now is "we don't know yet." But it's probably not worth another bug (especially on something that doesn't quite exist yet).
Comment 45 Marco Hunsicker 2009-01-27 15:32:12 UTC
It's a pity that this issue still hasn't been resolved. Showing some information about the two files in question seems like a sensible thing to do. The dialog mentioned in http://mail.gnome.org/archives/nautilus-list/2008-April/msg00065.html looks mostly good to me, though I would omit the rename part.
Comment 46 A. Walton 2009-06-16 09:44:01 UTC
*** Bug 585321 has been marked as a duplicate of this bug. ***
Comment 47 Mike Rooney 2009-06-17 22:16:00 UTC
Should this be re-targeted for 2.28 or 2.30 since it obviously missed 2.24? Cosimo, is your patch available anywhere and how usable is the state it is in?
Comment 48 Ferk 2009-06-18 14:03:19 UTC
Just an opinion, but I think that the rename option would be usable if the name is chosen automatically (instead of asking the user for the name every time).

It could just append to the original filename a string like "(2)"  in a similar way as the files are renamed to "copy(2) of name.ext" when you do control+c control+v on a file multiple times.

If the user wants to rename to another name it can be done manually later, but asking for the name would turn "apply to all" unusable.
Comment 49 kenden 2009-06-18 17:22:35 UTC
Link to new discussion about this feature on the mailing list:
http://mail.gnome.org/archives/nautilus-list/2009-May/msg00023.html

It has a link to Cosino's patch (comment 41):
http://git.gnome.org/cgit/nautilus/log/?h=merge_replace_dialog
Comment 50 pinco 2009-07-15 20:32:04 UTC
I think this bug should be resolved as soon as possible. I am not a programmer, but I believe that this scheme can be well done. 

http://www.lilik.it/~anarki/media/my/gnome/file-conflict.png
http://www.lilik.it/~anarki/media/my/gnome/file-conflict-rename.png

Thanks for your work, Paul
Comment 51 Donald 2009-10-24 19:04:24 UTC
Hey, folks, don't you think that 8 years without any action on this bug (none visible to the end-user, anyway) is a little ridiculous? A lot of interesting, but complicated ideas have gotten in the way of implementing the simplest possible improvement, which could have been done *4 years* ago: the "older / newer / smaller / larger / identical" modifier idea suggested by Joachim Noreiko. I don't think this simple change would have made any other suggestions mentioned here any harder to implement in the future, and yet doing it would have given users a (subtly but significantly) better experience right away. (If you don't see this as a useful comment in this discussion, consider it a general criticism/warning that can apply to many other existing and future bugs. As the saying goes, don't make the perfect the enemy of the good!)
Comment 52 Yann 2010-01-20 10:51:56 UTC
Hi all, any news about this?
Comment 53 Eduardo Pérez Ureta 2010-03-14 22:33:54 UTC
Created attachment 156146 [details]
nautilus merge replace dialog (null) when copying folders

I have been trying:
http://git.gnome.org/cgit/nautilus/log/?h=merge_replace_dialog
and found it still needs some care as when copying folders you get (null) in the shown properties.
Comment 54 Cosimo Cecchi 2010-04-13 16:35:06 UTC
Yeah, I fixed that bug in the branch, along with some others and some comments about the UI given from the usability team. This should be now in a good shape to be merged during the 2.31 development cycle.
Comment 55 Cosimo Cecchi 2010-04-26 14:55:18 UTC
I merged the branch to master, feel free to report any bugs in it :)
Closing this as FIXED.
Comment 56 Philip Gillißen 2010-04-27 07:57:28 UTC
Hi Cosimo!

Thank you for your patch!

Is it correct that now only the file date is displayed?
This would be helpfull, but file sizes would be great :)

Greetings
Comment 57 Cosimo Cecchi 2010-04-27 09:10:25 UTC
(In reply to comment #56)
> Hi Cosimo!
> 
> Thank you for your patch!
> 
> Is it correct that now only the file date is displayed?
> This would be helpfull, but file sizes would be great :)

No, also sizes are displayed in the new dialog.
Comment 58 Cosimo Cecchi 2010-12-17 10:19:27 UTC
*** Bug 637433 has been marked as a duplicate of this bug. ***