GNOME Bugzilla – Bug 143746
dnd should always move files - not copy them
Last modified: 2021-06-18 15:15:56 UTC
There already are several bugs concerned with the Drag & Drop behaviour of Nautilus. Nevertheless there is a more fundamental issue, I think: What should the default action of dragging a file from one folder to another be? Currently, the default behaviour changes, depending on whether a file is on the same file system or another one. I personally find this very confusing. For example, if I open one window in my local home and another in a remote home (via SFTP), I would expect to move a file when I drag it onto my local desktop and from my desktop into another local directory. Instead, a copy of the file is left behind on the remote home. Basically, the current default behaviour of sometimes do this, at other times do something other is exposing implementation detail to the user, and I don't think that the unexperiences user will understand the difference between different file systems.
*** Bug 147356 has been marked as a duplicate of this bug. ***
*** Bug 128227 has been marked as a duplicate of this bug. ***
I'm not sure i agree about the change, but lets keep this open for now and make it the dup-head for this issue.
Also related is bug 80694
One solution would be defaulting to always move, but when moving to external filesystems also leaving a copy in the Trash - so that the local file can be easily recovered (for example if the remote file wasn't transmited correctly).
There's quiet a chance that the remote folder which is your drag source is a collaborative one. Therefore, moving isn't usually desirable in that case either.
I really like the way KDE/Konqueror implements it: no default action, always show a context menu instead (like Windows does with right button drag). Of course any other "action chooser" would do. Having a default action based on locality is bad enough in Windows, but it's so much worse in unified (filesystems) namespace of *NIXes... IMHO file operations are too important/dangerous to have a default drop operation. I've never seem an OSS file manager that manages to make accidental drag'n'drop operations as likely as Windows Explorer does but, as people say, better safe than sorry ;-) Also, using an action chooser would allow better handling of read-only source or target (unavailable options could display disabled, with hints or comments for the reason it's disabled). BTW, I wonder whether the two following bugs should be marked dupe: http://bugzilla.gnome.org/show_bug.cgi?id=331643 http://bugzilla.gnome.org/show_bug.cgi?id=314139
Created attachment 70776 [details] [review] Proof of concept of consistent behaviour for file management.
I recently also got to the point where I was so annoyed by the "sometimes copy, sometimes move" that I decided to do something about it myself. My personal beliefe is that the behaviour when doing (drag and drop) file management in nautilus is that it should be _consistent_ (no matter what is the default action). Additionally I would prefer that the default action is move as that is what I do the most and the alternative behaviour being copy when I hold CTRL. (In other words: always act as nautilus currently does when you DND files on the same filesystem) This is what I believe is the most logical thing to do. Dragging stuff around the desktop in my opinion matches moving the files on the harddrive. Stupid people (;-P) like my parents can't handle stuff being copied, they drag their documents to the usb stick makes changes to it and then they have two different versions of the same file but doesn't understand that because they think it's the same document not being aware that the plus sign that appeared on the cursor meant that they copied the file. Please discuss this further with some usability experts.... I'm not one of them, it's just that the current behavoir gets on my nerves which means it's definitely wrong since I'm not usually picky about user interface stuff. :) It seems like the code to make nautilus current inconsistent behaviour was added on purpose, so to get a consistent behaviour all I had to do was to remove/disable that code, "proof of concept" patch attached. Discussions followed on IRC about why that code where there at all? Suggestions came up stating is was because moving to "remote" filesystems (usb-sticks, nfs shares, and so on) wasn't safe. (The usb-stick could be yanked before the file was synced and then the local file would be gone and the usb-stick file would be corrupt -> data loss) If this is the case I believe there's much better ways to work around the "brokenness" in the operating system that leads to possible data loss. One way that has been suggested above is to move the local copy to the trash so that it can be restored in case the remote copy was corrupted. Another would be to add an extra delay in the move dialog to make sure the data is synced to the usb-stick before it's removed. (Assuming the user waits for the dialog to close before yanking the stick and that worst-case time to sync is only a few seconds, which I believe is atleast true under Linux) The current behaviour doesn't prevent data loss because the user doesn't automatically understand that when holding down CTRL to move the files also means "don't yank the stick". There's also no check to see if the destination filesystem is a "remote" one at all. (ie. having 2 harddrives -> 2 partitions -> 2 filesystems and moving between them doesn't suffer from any of the usbstick/nfs/whatever problems but the default action is changed to copy anyway!) To sum it up: 1. I would prefer the the behaviour to be made fully consistent (as my proof of concept patch makes it), with move as the default action and copy as the alternative. 2. If you still disagree, I would like that extra code that checked if the destination filesystem is actually "remote" (usb-stick, nfs, sftp, ...) before going into "safemode" (changing the default action to copy) to make the inconsistency not appear as often as today. (ie. don't punish people with two permanent harddrives) 3. If all else fails, please give us anything but the current behaviour.. ;) Regards, Andreas Henriksson
Here are some additional patches to be considered. The first one makes move default for all local drives (while keeping it as is, default to copy, for remote destinations). The second one (should be applied on top of the first one) adds an additional check to discriminate memory sticks (other "we're afraid the user will yank them" device types can be added trivially in the switch). Regards, Andreas Henriksson
Created attachment 71044 [details] [review] Default to move if source and destination partition is both local drives.
Created attachment 71045 [details] [review] Add additional check that discriminates memory sticks on top of the previous patch.
Setting patches as obsolete, as Nautilus moved away from GnomeVFS.
The patches may be obsolete, but the bug seems to be fixed! Atleast the drag and drop defaults to move, both when I drag between folders on same filesystem and between rootfs and attached usb harddrive. Someone with permissions, please close this bugreport!
Thanks Andreas for the follow-up, closing as OBSOLETE. Feel free to reopen the bug or open a new one if this still happens.
Reopening, as I still see this behaviour with Nautilus 2.20.0 (Debian unstable).
Sebastian, can you verify that this is still a problem with Nautilus 2.22 too? Andreas, which version are you using?
Sebastian, nautilus 2.20 is still the old GnomeVFS based one. You need nautilus 2.22 from Debian Experimental!
Same problem with Nautilus 2.22 from experimental: When trying to drag a file over a NFS or SFTP mounted share, it shows the "copy" pointer, while it shows the "move" pointer over local folders.
Ok, I only tested between my rootfs and my usb harddrive. Previously (and what my previous patch removed) there was a check if copy was on same filesystem. I don't care too much about remote filesystems. Isn't UPLOAD (==copy) the expected default behaviour for remote sites? I can still see the complaints about inconsistency though. I guess I'll just remove myself from CC on this one as my issue is fixed and let you guys decide and handle the rest.
Sebastian: I don't think that having a single default action for every DnD (defaulting to move) is a good thing, and it really doesn't make sense to me for remote locations, as you will rarely need to move something from a local folder to a remote share, and that would be just confusing. If you really think that is the way to go, please send a mail to the GNOME usability and Nautilus mailing lists [1] [2], asking their opinion on the matter, so we can take a final decision. Thanks! [1] nautilus-list@gnome.org [2] usability@gnome.org
* drag & drop should always default to cp -p * after the drop, pop under the mouse pointer and ask if user wants to delete source files. * pop up dialog should have the option to record preferences for future use, i.e. - yes button (= move) - no button (= copy) - radio button for the cases to which the reply applies -- only this time (default - the pop under is shown after every drag and drop operation) -- always for this specific volume -- always for this type of media -- always and never ask me again - checkbox: preserve timestamps (default selected, = -p switch) A desktop is first and foremost about *choice* - there are as many ways of doing things as there are users. None is better of worse, they are just different, and they all work for their respective users.
A desktop (at least, the GNOME desktop) is first and foremost an environment that enables users to focus on their primary task without getting in the way. If it can't perform the simplest of operations in a sensible default fashion without first asking you what to do, it has unceremoniously fallen at the first hurdle. I don't really think the correct default behaviour here is something we can nail down by talking hypothetically about it. I'm pretty sure that the default move/copy behaviour is such a subtle nuance of the file manager that most users barely notice it. If they've ever used Windows or a Mac before, they will have been exposed to the same behaviour there, so they probably won't find it unusual. If this is their first exposure to a desktop file manager, they'll probably notice that their pointer goes a different shape sometimes, but not really understand why. Probably the only way to get to the bottom of it is by running a study in a controlled environment with a carefully-constructed set of tasks, which ask a cross-section of our users to perform various move and copy operations between various local folders, network shares and attached devices (without specifying how to do it of course). Through observation and debrief interviews it shouldn't be too hard to figure out if any operations are causing problems, confusion and/or data loss, to what type of user, and why. Only then can we really figure out what to do about it.
The poll: 1) Have you ever dragged and/or dropped a file by mistake or at the wrong place? 2) Have you ever did more than 3 file drag operations in a row? If you realize my previous post you'd guess my answers: 1) Yes, some times. 2) AFAIR, no. Conclusion: yeah, you guessed it. And please display some info for both the source and target of the drag operation in the dialog/menu ;-)
it's not the same behavior on Windows. * On Windows, whether copying or moving, timestamps are preserved (cp -p) * On Gnome, the last time I tried timestamps where not preserved when moving between volumes. Unsurprisingly, most users will ask the desktop to do what they are used to - no need for studies to determine that. Current Gnome users have learned to live with the current behavior. They most likely see no reason to change. If the goal is to cater to current Gnome users, close this bug, it is a non-issue. If <http://live.gnome.org/10x10> is still on the radar screen, consider that the majority of new users will be Windows converts. They too will ask the desktop to behave like they are used to. It's not better, it's not worse, it's just *different*. They won't be comfortable making a switch unless their desktop behave like they are used to. No need to sacrifice the existing user base to make inroads in this potentially larger user base. Both way of working have equal legitimation and it is in the interest of Gnome to cater to both, and this inevitably means *choice*. My suggestion above was just that: a suggestion. Don't like the pop-under idea? associate it with a right-click or put it in the preferences and that's it. I personally would be happy to just have the option to set the above behavior customization in the preferences. Also on Windows using "right click" gives me the option to decide if I want to copy or move. Want to be more flexible and accommodating? introduce a "mode" switch to the desktop: "cruising mode" and "learning mode". * In "learning mode", let the desktop pop up with questions every time a new situation arises to which the user has not yet set a preference. After a while, it has learned my preferences and no pop ups are necessary. * In "cruising mode" let it work without interruption based on preferences and defaults. Speaking of interruption, the focus-grab by the updater or by any other application is much more annoying, because it happens in unexpected moments while I am doing something else. The popup I am suggesting is just an extension of my current task, no interruption. It could be shown before execution. IMO it is in the interest of Gnome to be flexible and accommodating to grow its user base, but I know I have not much influence on the choices you guys make. I don't have the skills, knowledge, time to do what you are doing. I respect you for that. The only thing I can do is choose to use it or not, and to be brutally honest, after a recent attempt, I am back using Windows. Yuv
I think this bug report has passed its point of maximum usefulness. I suggest the Nautilus maintainers publish a design specification -- even a single-sentence specification that says "Dragging should move when {x} and copy when {y}" would be better than nothing -- so that bugs can be reported about details of where Nautilus doesn't follow the specification. For example, if the Nautilus help doesn't describe the behavior accurately, that's one bug. If dragging to an NFS share doesn't match the spec, that's a separate bug. If dragging to a portable music player doesn't match the spec, that's a separate bug. And so on.
The current default behaviour is "move if on same filesystem", otherwise copy. There might well be times when this is not really exactly what people want. However, in the most common case of one single local root filesystem where all other filesystems are shared NFS directories of pluggable things like USB sticks I think this does what most people expect (and I think, what other os:es do). Any kind of heuristics is likely to fail in some cases, so I think having the most simple one is a good idea. Its also the safer choice, as all sort of moves cross devices cause some risk of data loss (since we actually delete the source file). However, there is one other exception. If you move a mountpoint directory and drag it to the directory its already in (e.g. move the icon on the desktop) we also default to move (for obvious reasons). This behaviour regressed in 2.22 with the move to gio where we defaulted to move for *all* parents of the source (not just the immediate one). I just fixed this in svn, but this may be the source of a few issues people have reported with this.
Renaming for clarity (hopefully).
[Bumping version number as per comment 19]
How about just letting user to decide on this? Something like /apps/nautilus/preferences/file_dragdrop_policy, with values "old", "move", "copy". I feel that current behaviour is very inconsistent & annoying, but if other people feel that it's still a good default, then fine. Just let me to change that for myself.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.