nautilus 'replace file' dialog box could give more information

[Rocko]

Binary package hint: nautilus

(Wishlist)

When you try to copy a file into a folder and there is already a file with the same name, nautilus just says that the file exists and asks if you want to replace it.

It would be far more useful if it also displayed for each file:

* last modified
* file size

so that the user could make an informed decision as to which is the newer file.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Thank you for your bug report. I'm marking this as triaged and will forward upstream.

[Stephan7 (sshsteph007)]

In additional to above.. I found myself in a bad situation while I was copying thousands of files
from several sources to the same destination with the idea to merge all files in one directory.
Several had the same name, although they might or might not be the same kind.

The above dialog appeared with only the choices "skip all", "replace all", "skip" and "replace".
Several problems I have with this:
- At that moment I was not able determine if I want to replace or skip, so I wanted to investigate these files.
  But opening any other (new) nautilus window is prevented from exploring files/directories. It seems the dialog is
  blocking all nautilus user actions of every other window. It would be nicer if you could still work in other nautilus
  windows while the dialog is displayed for one.
- When I found that out I wanted to abort the action.. however there is no button for that.
  The close button does also not do anything, so the only possible approach seemed to kill nautlius.
- Also instead of skip or replace, I would like to have the option to rename the file to distinguish them.

Note that I like the option "skip all", as most filemanagers are limited to only three: replace "yes","no","all".

For those interested.. my workaround I used to overcome above problems.
For each source directory (many cdroms in my situation):
- first copy every source file (using select all) to an empty temporary directory
- secondly move all files from that temporary directory to the real destination directory and
  upon a conflict choose "skip all"
- if there was any conflict, the source files are still left in the temporary directory which I can
  then delete, rename or do some other action with.

[Rocko (rockorequin)]

I agree. It's even worse when nautilus hides the "skip all" etc window behind another nautilus window so that it just appears to have frozen.

It would also be a nice feature in the "skip all" window if nautilus continued to copy/move the files that is able to while it waits for your input. At the moment you can set up a 10000 file copy, leave the PC because you expect it will take a long time, and when you come back you discover it has copied only 10 files and is asking you about file 11.

[Homersp (maa-tillman)]

Agreed, it should display a bit more information about the files (size, date, etc).

[Michael Rooney (mrooney)]

Yeah, this seriously hinders usability. I was shocked the first time I realized I was going to have to go into the other folder, look at the size and dates, and compare them with the others file myself, for each file that already existed, each time I did this. Also I can't believe this has been a bug in Gnome for 7 years, and they even recently considered marking it as WONTFIX! This seems rather important/crucial for the default display manager of an OS.

[pe7er (pe7er)]

It could also show tumbs when coping images (.png .jpg .bmp etc).

[pe7er (pe7er)]

Here is example what konqueror does and nautilus should do:

[Psy[H[] (vovik-wfa)]

Upstream won't help. They just keep talking about some crap, like half a second time to read message and hit the button, so time/size info won't fit in this time. =O
It must be Ubuntu fix. Because it would never be fixed in Gnome with their "user-does-not-need-to-know-what-a-hell-is-he-going-to-delete" philosophy.

[Matthias Niess (mniess)]

Is any work being done on this? Especially for new users this behavior is really annoying. Filesize and modied times should be the minimum of information given on replacing files. If you have no information on what is being overwritten than you can just leave out the entire dialog because it doesn't make any sense.

[HughBranes (hughbranes)]

I don't use KDE, but I like very much that its file manager (what's it called this week?) has this kind of attention to detail. It impressed me the minute I saw it. Of course users can't make an informed decision without access to relevant information.

Perhaps if the concern is the delay required to gather this information, it could be hidden behind a "more details" toggle (one like that used in the GNOME update manager and others) and only generated on request.

[Volodya (volodya)]

I would also like to have an option to actually open the files, i'd suggest having an icon for target and destination files, with the tooltip with the information (alternatively information about files can be just written somewhere near the icon).

[Kostas Milonas (grimmoner)]

Yes!

Size, date, etc info would be very helpfull!

That would be a great feature!

[agitdd99 (agitdd99)]

I Absolutely agree on this one. I've experienced that replacing the same file not as simply as it shout be.

[Goran Zec (zecg)]

This situation is ridiculous. I had to abort the action I was doing and go do it from the console several times now. Date changed and size would be nice to have, but knowing if the file being replaced is older is absolutely essential.

[sportegioco (sportegioco-gmail)]

Yes, Yes, Yes,

Size, date, etc info would be very helpfull!

That would be a great feature!

[David Siegel (djsiegel-deactivatedaccount)]

Useful, but this does not alleviate a pain or frustration -- it's a new feature. Not a paper cut.

Looks like it is in progress upstream anyway, so no need for extra attention.

[Psy[H[] (vovik-wfa)]

I disagree. Without info about replacing files user has to find these files manually and look in their properties.
This is one of the most annoying bugs of usability.

[kenden (kenden)]

Also disagree, it fits perfectly the definition of papercut: system-wide, impact standard workflow, easy to address, problem with existing feature (rename/copy) and relates to usability and design.
https://launchpad.net/hundredpapercuts

And the progress being made upstream is only a 1+ year old discussion about design on the nautilus mailing-list.

[Michael Rooney (mrooney)]

On Wed, Jun 17, 2009 at 10:29 AM, kenden wrote:
> Also disagree, it fits perfectly the definition of papercut: system-wide, impact standard workflow, easy to address, problem with existing feature (rename/copy) and relates to usability and design.
> https://launchpad.net/hundredpapercuts

I am not sure if it is trivial to fix as you say, I don't even see a
patch attached to the upstream report. However feel free to prove me
wrong by attaching a good patch or providing a debdiff, or better yet
a PPA!

[Ferk (ferkiwi)]

I have to agree with the previous posts.
I think that this is an merely an usability and design issue (it makes replacing only the older files painful) about an existing feature (the dialog for replacing a file), it's not an entire new feature itself.

Which is exactly what papercuts are about (they even mention nautilus, and file-copying as examples). I couldn't think of an usability issue more suited than this one to be fixed for 100papercuts.

And kenden is totally right about upstream discussion.

[David Siegel (djsiegel-deactivatedaccount)]

Ok, let's reconsider this as a paper cut. Psy[H[], kenden, ferk, will you please investigate upstream about whether this will be trivial to add? The upstream bug has been open for eight years, so my guess is that it's not simple to fix.

This is not a paper cut because, although you might not consider this a "feature" per se, it is in the sense that it requires more than a few lines of code (my guess is at least 50 lines of C) to address. If this turns out not to be the case, great.

[Michael Rooney (mrooney)]

On Wed, Jun 17, 2009 at 4:31 PM, David Siegel<email address hidden> wrote:
> Ok, let's reconsider this as a paper cut. Psy[H[], kenden, ferk, will
> you please investigate upstream about whether this will be trivial to
> add? The upstream bug has been open for eight years, so my guess is that
> it's not simple to fix.

I've asked on the upstream tracker if a patch could be provided, as
there are some screenshots of functional versions and a developer
claiming to have a patch for potential merging. If I can get one I'll
throw it in my PPA and it can be evaluated. The patch probably won't
be trivial but maybe it would be useful to evaluate as a usability
issue anyway, just not a paper cut. It still seems preferable that
upstream nautilus supply this behavior though.

[Psy[H[] (vovik-wfa)]

The problem in the upstream is that some developers consider information about replacing files excessive.
http://bugzilla.gnome.org/show_bug.cgi?id=47893
see comments 15, 17, 23 and proposals about hiding info by default.
I personally like proposal in comment 14, but without hiding the first section. because when it comes to rapid decision about several files that will result in excessive annoying clicks unhiding info about each file.

[Michael Rooney (mrooney)]

Hey David, I don't know if you have any one else working on this, but
I've tested the patch locally and it seems like an improvement. If you
like I can get a PPA up for testing.

[David Siegel (djsiegel-deactivatedaccount)]

Great progress is being made on this, but for now I am replacing it in this round with bug #387680, which is more of a paper cut and less of a new feature than this issue.

[Hendrik (joker-x)]

Sorry for ranting, but this is ridiculous. I can't believe I'm still seeing this issue in Karmic. This bug was opened more than two years ago; the last message is five months old, saying "great progress is being made on this". Well, I don't see it.
I don't want to attack anyone personally, but on the whole, not getting this problem fixed is unworthy of what aspires to be a modern operating system.

[pinco (sportegioco)]

It's really impossible to close this bug? I believe not. When i copy many file i must use dolphin. I use dolphin only for this! It's not a good think. Please work on this bug!
Thank's
Pinco

[Psy[H[] (vovik-wfa)]

A good papercut for Lucid.
long-lived and annoying...

[Xavier Guillot (valeryan-24)]

I fully agree, at least Nautilus could tell us, on the "replace warning" box, dates of source and destination file, and perhaps the size, in order to make the decision easier (than cancelling and go to verify).

Or have an option to enable to get this information when a file has already the same name as one we want to copy.

[Ioannis Varsamis (varsamakos)]

I agree. Totally.
The examble showed in comment #7 is a nice one.
Let's say that thumbnails isn't the first priority here. Well, files' prorerties are.
Users should know more about that dialog.

[Hernando Torque (htorque)]

Over eight months after "Great progress is being made on this" - any news on this?

[phede92 (phede92)]

a parte "sostituisci file" in nautilus è la più incompleta ci devono stare le opzioni più essenziali (sostituisci tutto, sostituisci solo questo file oppure non sostituire9 e inoltre si devono aggiungere le informazioni dei file.

[Leo (leorolla)]

Hey people, please,

We should stop posting "It also could".

This bug has a very specific scope.

Something very simple, and very urgent: "display file information when propmting to replace".

Sophisticated solutions are proposed on other bug reports.

[Sergio Zanchetta (primes2h)]

@phede92
Please comment in English, otherwise the most part can't understand. Thank you.

Ciao, devi commentare in inglese, altrimenti nessuno capisce niente di quello che scrivi, ok?

[Isak Frants (isakfrants)]

Fixed in master by Cosimo Cecchi!

http://git.gnome.org/browse/nautilus/log/
http://git.gnome.org/browse/nautilus/tree/libnautilus-private/nautilus-file-conflict-dialog.c

[Sebastien Bacher (seb128)]

the issue will be fixed in Ubuntu next cycle

[Leo (leorolla)]

The bug tracker couldn't get the correct status from https://bugzilla.gnome.org/show_bug.cgi?id=47893

[Lonnie Lee Best (launchpad-startport)]

See the attached image for a side by side comparison.

[Vish (vish)]

Fix has been committed upstream and as Sebastien mentions will be available in the next release

[Lonnie Lee Best (launchpad-startport)]

Why can't an enhancement like this be in an update, rather than having to wait until an entirely new release?

[Leo (leorolla)]

https://wiki.ubuntu.com/StableReleaseUpdates

[Sebastien Bacher (seb128)]

because non trivial changes would require lot of testing and debugging, it would also require translating the new strings in the language which are supported in ubuntu

[Vish (vish)]

@Leo , there is no need to manually change the status of the upstream task, the bug tracker will update on its own. [sometimes slowly ;-) ]

When we have the link for the upstream bug at the top of the bug report , it is easier than searching for the upstream bug link in the comments.

[svaens (svaens)]

looking forward to this one!! Thanks guys!

[Sebastien Bacher (seb128)]

the change goes with quite some refactoring and will not be for GNOME 2.32 but for GNOME3, that's probably not something we will backport this cycle then

[Matthias Niess (mniess)]

I am pretty sure this has already been fixed in upstream nautilus. At least it is in nautilus-elementary and the developer stated somewhere (can't remember where exactly) that the new replace-dialog is not his doing but a benefit from just using the latest nautilus version.

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:2.31.6-0ubuntu1

---------------
nautilus (1:2.31.6-0ubuntu1) maverick; urgency=low

  * New upstream version:
    - This release is based on 2.30.1
    - Expand and collapse folders with +/- in list view
    - Rename .desktop files also change their name on disk
    - Support overriding .gnome2 directory
    - Save passwords for the session by default
    - Remove deleted folders from the pathbar (lp: #19069)
    - Replace libunique with GApplication
    - Don't show 'File Browser' anymore in the window title
    - Port to GDBus
    - Change the default order for files in special directories (lp: #404150)
    - Support relative paths in the location entry/dialog.
    - Use folder icons as window icons in browser and spatial mode (lp: #43608)
    - Add 'Trashed On' and 'Original Location' columns in the trash
      (lp: #301552)
    - Implement transparent icons for cut files (lp: #194213)
    - Change default thumbnail size
    - Fix a number of bugs related to bookmarks (lp: #534043)
    - New dialog to handle conflicts within file copy/move operations
      (lp: #136702, #263338)
    - New button in the trashbar to restore selected items (lp: #553600)
    - Use async I/O to save .gtk-bookmarks
    - Fix a number of issues related to DnD in the places sidebar (lp: #73031)
    - New icon for audio preview
    - Don't show Unmount when showing Eject/Safe Removal
    - Bump libnautilus-extension API version
    - Fix a number of UI glitches
    - Translation updates
    - Eat Control + v to not enable type ahead (lp: #52131)
  * Updated .install files for the gir
  * debian/control.in:
    - build-depends on dh-autoreconf, gobject-introspection and required gir
    - don't use libunique and libdbus-glib
    - list the new gir1.0-nautilus-2.0 binary
    - updated the gtk and glib requirements
  * debian/patches/16_hide_unmount.patch,
    debian/patches/git_browser_title_cleaning.patch,
    debian/patches/git_clean_by_name_rename.patch,
    debian/patches/git_correct_delay_logic.patch,
    debian/patches/git_correct_display_name.patch,
    debian/patches/git_correctly_set_default.patch,
    debian/patches/git_ctrlq_close.patch,
    debian/patches/git_default_thumbnails.patch,
    debian/patches/git_double_click_launcher.patch,
    debian/patches/git_no_double_browse_entry.patch,
    debian/patches/git_store_session_passwords.patch,
    debian/patches/git_typo_fix.patch:
    - the changes are in the new version
  * debian/rules:
    - call dh_girepository
    - use dh-autoreconf
 -- Sebastien Bacher <email address hidden> Thu, 12 Aug 2010 16:41:04 +0200

[Marcus Uneson (marcus-uneson)]

While knowing size and last modified are useful things to know,
they are not necessarily enough to tell that two files are identical
(in particular as sizes are usually only approximate).

Better would be to have the system find out for me that
the two files are identical by computing a checksum (md5 or similar)
in the background and let me know the result: "Note: the files
are identical", or "Note: the files are not identical". This is
very quick on all but the largest files (you may want to ask
specifically for *.iso and similar).

[Phil-ganchev (phil-ganchev)]

I agree. I filed this bug upstream: https://bugzilla.gnome.org/show_bug.cgi?id=654289

[Marcus Haslam (marcus-haslam)]

I'm out of the office until 1st August.

On 29 Apr 2011, at 16:30, Marcus Uneson <email address hidden>
wrote:

> While knowing size and last modified are useful things to know,
> they are not necessarily enough to tell that two files are identical
> (in particular as sizes are usually only approximate).
>
> Better would be to have the system find out for me that
> the two files are identical by computing a checksum (md5 or similar)
> in the background and let me know the result: "Note: the files
> are identical", or "Note: the files are not identical".  This is
> very quick on all but the largest files (you may want to ask
> specifically for *.iso and similar).
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/136702
>
> Title:
>  nautilus 'replace file' dialog box could give more information
>
> Status in One Hundred Paper Cuts:
>  Fix Released
> Status in Nautilus:
>  Fix Released
> Status in “nautilus” package in Ubuntu:
>  Fix Released
>
> Bug description:
>  Binary package hint: nautilus
>
>  (Wishlist)
>
>  When you try to copy a file into a folder and there is already a file
>  with the same name, nautilus just says that the file exists and asks
>  if you want to replace it.
>
>  It would be far more useful if it also displayed for each file:
>
>  * last modified
>  * file size
>
>  so that the user could make an informed decision as to which is the
>  newer file.