Changing to "old" target milestone for all bugs laying around with no milestone set.

Adding GNOME2 keyword.

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.]

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

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.

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

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

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?

I am attaching an ugly as sin dialog for doing this. Maybe we can get someone to
do within the 2.12 cycle.

Created attachment 46071 [details]
Test file dialog box

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

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

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

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.

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?

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?

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.

Created attachment 48083 [details]
Dialog box mk3 - default unexpanded view

Default, unexpanded view of the dialog box.
I've made the text more concise.

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.

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.

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

You guys might want to move this discussion to nautilus-list for wider feedback.

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.

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.

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.

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.

Yes, I'm thinking the same thing.
Let's get the basics into this dialog and worry about making it perfect later.

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!

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

Mass reassigning bugs with 2.2.0 milestone to 2.2.x milestone

Grep for "Mass reassigning" to filter out this bug spam.

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

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.

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??

Uri, do you want to create a patch? I can probably help with it, so this problem will be solved easily.

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.

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

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.

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

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

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

I have made a patch for this, I think it will be reviewed/merged for 2.24.

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

Does the patch also simplify the "overwrite all", "skip all" buttons with an "apply to all" checkbox, or should I file another bug?

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).

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.

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

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?

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.

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

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

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!)

Hi all, any news about this?

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.

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.

I merged the branch to master, feel free to report any bugs in it :)
Closing this as FIXED.

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

(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.

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