Will dragging a file result in a move or a copy?

Some people are confused by the seemingly random behavior when you drag a file. Do you get a move or a copy?

And you're right to be confused because it's not obvious until you learn the secret. Mind you, this secret hasn't changed since 1989, but an old secret is still a secret just the same. (Worse: An old secret is a compatibility constraint.)

  • If Ctrl+Shift are held down, then the operation creates a shortcut.
  • If Shift is held down, then the operation is a move.
  • If Ctrl is held down, then the operation is a copy.
  • If no modifiers are held down and the source and destination are on the same drive, then the operation is a move.
  • If no modifiers are held down and the source and destination are on different drives, then the operation is a copy.

This is one of the few places where the fact that there are things called "drives" makes itself known to the end user in a significant way.

Comments (80)
  1. Cooney says:

    If I mount a volume under c:stuff and drag a file from c:dev to c:stuff, does that count as a move or a copy?

  2. Aaargh! says:

    Will this ‘drive letters’ disaster ever completely disappear from windows ? maybe with the eventual introduction of WinFS ?

  3. Hey! says:

    Alt also works for a shortcut.

  4. Hmmh…

    I thought there was a situation (involving dragging .EXE’s around) that will create a shortcut when no modifier is pressed… But I neither seem to be able to reproduce it nor do I remember what has to be done. Maybe I’m hunting ghosts?

    This Drag & Drop story is the reason why I always drag using the right mouse button. This way, a menu appears on dropping asking you what to do.

    This prevents me from doing stupid mistakes…


  5. Alan Stokes says:

    There weren’t any shortcuts in 1989 (they were added in Windows 95), so at least part of the secret must have changed since then.

  6. Some more says:

    Don’t forget:

    dragging the file with your right button pressed let you choose your action as a context menue

  7. Mike Dunn says:

    The behavior when you drag an EXE has changed, no? I don’t have Win 95 installed (heh) at the moment to check if it does this, but in XP if you drag (with no keys down) an EXE that is listed in HKLMswmswincvApp Paths, the default is to make a shortcut.

  8. Joe says:

    This would all have been a lot less complex if the default had been to move always.

    If you have a mounted drive then IIRC windows tries to pretend that it is all part of the same physical thing so the logic above holds, but things get interesting in practice because explorer expects the move to happen instantaneously (so no progress dialog) but the disk thrashes for ages and there is sometimes confusion over whether the files are there or not.

    Also the secret above does not take account of network drives where you don’t know anything about physical storage at all.

  9. asdf says:

    This thing seems pretty obvious to me. If you get lost you can always use the context menu approach or look at the cursor with the various modifier keys held down (it changes to something intuitive).

  10. Ilya Birman says:

    2 Aaargh!:

    There is no disaster. Drive letters rule. If you don’t get it… Well :) You have to try to get it Ж)

  11. James Curran says:

    Your description should also cite the helpful nmenonic : "’C’ for ‘Copy’, ‘C’ for ‘Ctrl’"

  12. Isaac Lin says:

    Also note that the "ghost" icon under the mouse pointer changes depending on what will be done: a "+" appears if the file will be copied, and an arrow if a shortcut will be created. If you switch back and forth between hovering over a destination on the same drive and one on another drive, you will see the + appear and disappear.

    I always forget which modifier key is used for move and rely on the visual indication to remind me (I usually try Alt first, and the little arrow reminds me it’s the wrong choice).

  13. lowercase josh says:

    IIRC, ctrl+shift would sometimes bring up the context menu asking what you wanted instead of creating a shortcut. (despite the mouse cursor feedback telling you it was going to make a shortcut) I haven’t tried it in a long time though.

  14. James Risto says:

    Someone above wanted to get rid of drive letters … if you just have C:, you can (mostly) ignore it. Everything will be relative to C:. And if you add new drives, you can add them as a subdirectory under C:, just like Unix. What bugs me is that move/copy do different things with NTFS permissions; one "brings" its permissions, the other "inherits" from the target directory!

  15. simon says:

    and if you copy to a junction pointing to another drive?

  16. John Topley says:

    I think I read somewhere that drive letters are finally hidden in Windows Longhorn, can anyone confirm or deny this?

  17. dennis jackson says:

    The different handling of file dragging w.r.t. drive letters also comes into play if you use the subst command to map a local directory to a drive letter. Even though you may be moving a file from the same drive into a different path on that drive (via the subst), the file drag defaults to copying.

  18. Jack Mathews says:

    Dragging to the Start Menu or a toolbar on the taskbar are exceptions where they create shortcuts by default.


    I believe the Shortcut behavior existed when dragging in OLE – Holding Alt or Ctrl-Shift would create a link.

  19. Cooney says:

    Sorry raymond, I don’t have a spare partition handy. At any rate, it was more a question of how consistent windows is being about abstractions, or if the abstractions are just a retcon to explain existing behavior.

  20. camillo vezzoli says:

    Raymond, this has always bugged me… why a different behaviour when dragging between folders on the same drive and folders on different drives? I’d love if the answer were "decision taken by the software engineer without informing anybody"… instead there’s probably an usability study behind this choice.

  21. Wes says:

    Here’s an interesting reader on why one guy thinks Windows behaves in this way…


    (go down to point 4 and read it through)

  22. Raymond Chen says:

    The rationale was so obvious to me I didn’t think it worth explaining. (Confirmed by usability testing.)

    Drag a file from a CD to your hard drive – you obviously want to make a copy from the CD.

    Drag a file from your hard drive to a floppy – you obviously want to make a copy to the floppy.

    Drag a file from one folder to another in My Documents – you obviously are rearranging files in your My Documents folder.

    This is one of those "do what I mean" things.

  23. camillo vezzoli says:

    My love for you is strong, but after this answer it’s fading…

  24. Jack Mathews says:


    I’m pretty sure the "hard drive to hard drive" case is the one that most people are annoyed about.

    I’m sure the usability answer is "don’t have multiple drives."

  25. Don’t forget about dragging files using the right mouse button.

  26. Raymond Chen says:

    Remember that in corporate scenarios, all documents are kept on a network drive, not a hard drive, so any rules for "move vs copy" must treat network drives and hard drives the same so that the behavior is the same in corporations as at home.

    Therefore, the rule for hard drive-to-hard drive must be the same as network-to-hard drive, and network-to-hard drive is clearly a copy operation. (You want a local copy of a shared document.)

  27. Adam says:

    On Win98SE, if I drag an EXE file to another directory on the same drive, the default is to make a shortcut. If I ctrl-shift-drag (any type of file), I get the menu.

  28. Brent Dax says:

    "This is one of the few places where the fact that there are things called "drives" makes itself known to the end user in a significant way."

    <bigot>Unlike Unixes (and OS X, sort of), which just mount other drives to the root file system so you don’t have to worry so much about it.</bigot>

  29. Ivo says:

    If you drag a file to the "Quick launch" toolbar it creates a shortcut, but the mouse pointer doesn’t change accordingly…

    Something that really bugs me when dragging files in the explorer is that the tree view doesn’t show the target folder correctly. If I roll the mouse over a folder it gets selected. If I move the mouse few pixels above or below the selected folder the selection doesn’t change. But if I drop the files they get dropped into the folder under the mouse and not the selected one. When would they finally fix that!!

  30. ShadowChaser says:

    Of course, this gets a lot scarier when you add NTFS into the mix.

    Moving always seems to keep the permissions, regardless of whether or not the destination parent folder has permission propigation turned on :(

  31. Vorn says:

    Extending James Curran’s mnemonic:

    A alt

    A alias (another name for a shortcut, used by MacOS)


  32. Raymond Chen says:

    Unix doesn’t have drive letters but it still has drives. You just don’t see them. Instead you get EXDEV occasionally.

    You can use mount points to get the same effect on Windows – mount all your drives inside a single tree.

  33. njkayaker says:

    Keep in mind the following:

    A move within a drive is effected by shuffling directory entries. A move to a different drive is effected by a copy and a delete.

  34. Chris says:

    As njkayaker reminds us, my impression has always been that this behavior is at least partially because moving a directory entry in the same file system is easy, while moving between drives or partitions invloves moving all the bits and is much slower (think about dual floppy drive systems, or even worse, singe floppy systems). Combine this with Raymond’s "do what I mean" rationale and there you go.

    Something that IMHO could lessen the usability impact is to only have separate drives or partitions where the user can physically see the separation (like CD drives or external hard drives). Always treat internal storage as one big file system independent of its actual hardware implementation. Luckily, most end-user PC’s are like that.

  35. Chris says:

    Hmmm, my first point about moving between drives being slower as a reason for this behavior makes less sense now that I read it. I’m not sure what I was trying to impart. I know I’m leaving something out.

  36. ssge says:

    Now you only have to explain why there is a difference in the behavior when the source and destination are on different drive vs. the same drive.

  37. ssge says:

    I submitted my comment in a haste (and before reading the previous comments)

    What I meat is that there isn’t a good reason why there would be a change in the behavior of an same operation for something as obscure as the drive.

    The design guidelines I am following say that you shouldn’t change the verbs of the operations unless you have modifiers.

  38. Jon Potter says:

    Use Directory Opus and you can configure the drag and drop action to do whatever you want :)

  39. Raymond Chen says:

    To answer "What happens if…", **try it** and report back.

  40. Merle says:

    Windows (at least 2kpro) also treats subst’ed "drives" the same as physical drives.

    So if you "subst y: c:" and drag a file from c: to y:, it makes a copy.

    What’s wrong with drive letters? I’ve lived in both Unix and Win/DOS worlds. Both ways have benefits and drawbacks… but dropping drive letters would be a *huge* bomb for backwards compatibility. Just a simple example: games that look for the CD by enumerating physical optical media drives and walking through them…

  41. Merle says:

    Or you can always just *explicitly* cut or copy using keyboard shortcuts.

    I tend to use the keyboard anyways, so never really noticed the copy/move aside from some "hmm" moments watching other people use their computers. But if you Ctrl-XCV between separate Explorer windows, there’s never any doubt about what it will be doing.

  42. Brian says:

    Drag vs Move has never annoyed me much because it tends to be "do what I mean" as Raymond suggests. The one that really annoys me is when it makes a short cut. I never want to make a short cut by dragging with my left mouse button (unless I hold ctrl+shift, I suppose).

  43. Michaël Van Dorpe says:

    Extending on Vorns’ and James Currans’ mnemonics:

    ShortCut > ShiftControl!

    It’s so obvious, but I’m still happy I found this :-)

  44. Keith Moore [exmsft] says:

    I prefer to just use COPY and MOVE from the command line, but then again, I’m a troglodyte…

  45. David Pritchard says:

    Re the "don’t show me drive letters" thing: hiding drives and just showing you a single unified "file space" would result in another one of Joel’s "leaky abstractions". You might want to avoid thinking about where files are physically stored, but sooner or later you have to think about it because the storage media are different. CD-ROMs aren’t writable; moving on the same hard drive is quick, moving between hard drives is much slower; etc. Eventually reality intrudes on our nice abstractions.

    I like the copy/move behaviour. I’ve always liked it. It seems totally intuitive, and I’m always surprised when people are unaware of it or confused by it.

  46. Sriram says:

    Actually, I use right-click drag all the time. This way, I get a menu which tells me my options and then I can select a move or a copy instead of remembering these rules

  47. IceTheNet says:

    ctrl x = cut

    ctrl c = copy

    ctrl v = past

    ctrl a = select all

    using these methods for file transfer is far faster than drag and drop and more accurate if you do insist on drag and drop the then windows xp has a nice little + sign that lets you know before you let go of the mouse what is going to happen. you will notice that if you hit the control key while draging it will show up that means you are about to add the contents instead of move. nice but if you learn your controll keys you will notice that windows dosnt need to figgure out what you are doing and thus a more rapid move.

  48. David Pritchard says:

    The "nice little + sign" has been there since Windows 3.x.

  49. Kevin says:


    FYI, a situation where the rules do not apply. I have a Canon digital Camera and when the camera is mounted (USB device) a supposed "Move" operation results in a copy not a move. I had a discussion with some digital camera guys and they tried to tell me that is correct behavior.

    So it seems Canon does not like the MSFT definitions of file operations.

  50. Norman Diamond says:

    11/12/2004 8:29 AM Raymond Chen

    > To answer "What happens if…", **try it**

    > and report back.

    Are you sure? Whatever they report back, a dozen programmers will rely on, someone will include it in a book, and then when you change the undocumented spec you’ll find hundreds more compatibility shims that you’ll have to write. (And your time spent writing those shims will be time not spent undoing new additions of bugs in other Windows components.)

    Meanwhile, I will try to practice with using the mouse’s right button to do all my intentional copying and moving, probably won’t remember all the time but will try to because of its obvious benefit. BUT THAT IS NOT ENOUGH. 90% of my use of the mouse’s left button to do copying and moving is unintentional. My finger falls asleep on the button while moving, or my hand slips while clicking. Whichever it did, a copy or a move, I have to figure out what it did and undo it. This problem will not go away by using the right button for the 10% of the cases where my dragging was intentional. Can an option be added so that dragging by the left button will also bring up a menu?

    One of the occasions where I intentionally do a drag is in the Start menu. After adding an application, I want to move shortcuts for Explorer and Command Prompt back to their usual positions so I can click on them easily. (And yes since Windows 2000 I’ve been putting copies of those shortcuts in the Programs folder.) Just to add to the pain, sometimes when I’m doing this, some application or some service pops up a window, so the Start menu that was opened gets closed, and the shortcut that I was trying to drag into position now gets moved onto the desktop. A menu with a "cancel" option would be nice.

  51. Raymond Chen says:

    That’s why wrote said try it *and report back* not "try it and write code that relies on it." Though how you can write code that relies on button click behavior in the shell I don’t know.

    I find it ironic that you’re asking for more confirmation dialogs; most tech-savvy users complain that Windows has too many confirmation dialogs, not too few.

  52. Moi says:

    You do realise that "right mouse button" and "left mouse button" is brain warping for those of us who are left handed.

  53. Cooney says:

    Also, single click vs. double click is a major challenge for a large number of people.

    I will dispute the right/left brain warp – when I use a mouse in my left hand, my index finger sits on the ‘left’ button (after a button swap), so I just don’t think about it. Perhaps a dominant/alternate button metaphor would work better.

  54. Peter Ibbotson says:

    I’m with Keith Moore on this one, whats wrong with copy and move from the command line? (particularly with cmd.exe command line completion)

    If I do use explorer then I tend to use either cut/copy/paste OR the "move to" "copy to" menu items.

  55. Medve says:

    It’s funny to see people spending so much time explaining and arguing about something which is so obvious if you use a Commander-style program instead of Explorer (and btw it’s also so muuuch faster…), where you don’t use the mouse, and can tell explicitly what you really want to do: F5 is copy, F6 is move…

    It’s always a pain in the @ss when I get to a machine that does not have *** Commander installed – usually this is the very first thing I install on a fresh system.

    Btw. the one thing that I explicitly HATE about user interfaces is when it tries to be smarter than I am, and tries to guess what I want to do… It’s even worse if it has no alternatives (I recall working on a Mac… now that was a horror…).

  56. Mat Hall says:

    "My finger falls asleep on the button while moving, or my hand slips while clicking. Whichever it did, a copy or a move, I have to figure out what it did and undo it."

    Just press Ctrl+Z. (I only found out that this works by accident — I have one of those new fangled MSFT keyboards with an F-Lock key which defaults to off*, and F2 does an undo. Many’s the time I’ve copied a file, gone to rename it, and got a "Are you sure you want to delete the selected file(s)?" dialog.)

    I don’t think it ever occurred to me that there could be any confusion in this area — drag from drive to drive: copy, drag from folder to folder on same drive: move, add modifier keys if it’s not what you want. The "drive mounted as folder = other drive" may cause confusion amongst those unfamiliar with mounting folders, but that’s an edge case and unlikely to affect the average user.

    * I have no idea why it defaults to off, what possible benefit this provides, and most importantly why I can’t change the default behaviour, but I’m sure there’s some sort of focus group or usability study that tells me that it’s my fault I’ve got used to my keyboard always working the same for the past who knows how many years. And don’t even get me started on the changes to the Ins/Home/Etc. cluster, the fact that PrintScrn doesn’t seem to work properly any more — sometimes it grabs a screen bitmap, sometimes not — and countless other things. :)

  57. Marc says:

    Is there a way to disable drag’n’drop. I mean copying or moving a file by dragging it without pressing an modifier. May be it’s just me* and I may be motorically challenged, but it often happens that I accidently copy or move files. Ok I know now that I could undo that with ctrl-z. But sometimes I don’t even realize that I moved some folders.

    *I don’t hope that I’m the only one because that would make me sole responsible for the mess that sometimes happens on some network drives. ;)

  58. Jerry Pisk says:

    I ran into the same issue as Mat, move a file and when trying to undo that action Windows asks if I want to delete the file. No I don’t, I want to move it back to where it was.

    But since this is about dragging files – I think that usability study reflects regular users, who have no concept of files. As a programmer when I drag a file over I want that to be a move, even if it’s to a floppy. The same way like when I drag text in Word it will move, not make a copy if it’s being dropped on a different page.

  59. Norman Diamond says:

    11/14/2004 7:32 PM Raymond Chen

    > I find it ironic that you’re asking for more

    > confirmation dialogs; most tech-savvy users

    > complain that Windows has too many

    > confirmation dialogs, not too few.

    True in many cases. For example in batch scripts, it is common to not want confirmations for situations that are already expected and have handlers for them.

    For operations whose invocations have more likely occured by accident and are unwanted, rather than having been intended, confirmations are very highly appealing.

    Of course most Windows users have fingers that are less clumsy on the mouse than mine are, so they wouldn’t want this geeky^H^H^H^H^Hantigeeky confirmation. That is why I suggested adding an OPTION to put up the same confirmation menu for left-button drags as for right-button drags.

    11/15/2004 2:37 PM Jerry Pisk

    > The same way like when I drag text in Word

    > it will move, not make a copy if it’s being

    > dropped on a different page.

    Yup, my clumsy fingers sometimes move things in Word too that I didn’t want to move. I have a feeling I’ve seen an option to disable that, and maybe I should look for it. But it hasn’t hit me as often in Word as it does with other Windows operations.

    11/15/2004 8:04 AM Moi

    > You do realise that "right mouse button"

    > and "left mouse button" is brain warping for

    > those of us who are left handed.

    Yes, but I don’t exactly know what else to call them. When I started using mice, right-handed users had button 1 on the left and button 3 on the right, and left-handed users had them the other way around. Button 2 was always in the middle. Later I used a mouse that only had a button 2 — of course the maker didn’t call it button 2, the maker just called it the button, and the designer said that a mouse with more than 1 button is defective (and then how many buttons did that designer put on his Next mouse…).

    Anyway, you’ll be glad to know that Microsoft does provide options for handedness. Go into Control Panel, click the Mouse icon, set an option, and your Microsoft Mouse suddenly changes into its mirror-image shape. Or something like that.

  60. Steve P says:

    Weird. I’m left handed, and have *never* needed or wanted to swap the buttons over. In fact, resting my hand straight on the mouse just feels damn alien.

    I tend to use my index finger for both the left and right buttons, and my other fingers just hold the mouse.

    However when I do have to use a mouse right handed, I have my index finger on the left button, my middle finger on the right, like how I imagine you unnatural right-handers use it.

    Oh, and to stay on topic – I have had problems with move vs copy, so, if I’m using the mouse, all I do now is pay more attention to the little icon, or explicitly use the context menu cut/copy and paste.

    It seems to be a simple rule, but if I’m copying between several very deep directories, I tend not to be focused on whether the drive letter is the same or not.

  61. Ed says:

    Hey Steve P –

    I’m a fellow lefty, and I use the mouse the exact same way. I don’t feel as wierd anymore.

    Oh, and I right-click drag *every* time. I don’t want the machine guessing what I want to do.

  62. Brian says:

    RE: Newfangled keyboards with F-Lock defaulting to off

    I actually wrote to Logitech about this and they essentially told me to go f myself.

    Here’s my favorite bit:

    "Since the F keys (F1-F2, etc) are not commonly used in many applications, they now can be re-programmed with other functions"

  63. David Pritchard says:

    This argument demonstrates conclusively that Microsoft can never, ever win, no matter what it does.

  64. Stern says:

    A related question: why does Explorer sometimes behave as if a modifier key was pressed when dragging files? Typically Explorer will default to "copy" even though you’re moving files between adjacent directories on the same drive, and you have to do a little dance on your control and shift keys to restore things to what they should be.

  65. Chris says:

    I’ve never had a problem with this behaviour when working in Explorer – maybe I’m an old-timer but the defaults seem very intuitive to me.

    The one case I find VERY irritating and inconsistent is the handling of special folders (Desktop, My Documents etc). Logically, these should be a "drive" of their own for move/copy purposes (i.e. dragging from the desktop to a folder on ANY drive should be a copy) – however, Windows doesn’t do this and instead relies on the physical drive (i.e. dragging a desktop item to/from C: is a move, desktop to/from D: is a copy).

    The whole idea of the Desktop and My Documents model was to avoid users having to know where the files are actually stored – and in that respect it worked, and not many users know which hard disk their Desktop exists – but in this case the abstraction is lost and from most user’s perspective the behaviour is unpredictable.

  66. Chris Becke says:

    Logical containers would make much more sense. "My Documents" is much more like a cd-rom than the entire contents of c:

    If I drag a file from somewhere inside "Start Menu" or "My Documents" to some other place within the same logical container then i clearly want to move it. If I drag it from "My DocumentsSome Files" that just happens to be on c-drive to "c:My BackupsSome Files", I clearly want to copy it not move it.

    The problem is explorer cam out with this really namespace concept, and things like "My Documents" but always exposed the entire filesystem as a place to store documents.

    It might have been more valuable to draw more strongly the distinction between folders and directories. I mean, I can see so many holes in this concept, its riddeled with interface leakage, but if there was some concept of being in a sub folder ultimately parented to "My Documents" then dragging files around inside "My Documents" would result in a move, and dragging into a seperate folder structure (or into the raw filesystem directory structure) would be a copy.

    I dont know if anyone other than me can make any sense of that – trying to load different meanings onto folder and directory, such that folders contain documents, but directories contain files. The widows shell implies the difference but ive never really seen an official ms explanation that a folder is a directory but a directory isnt a folder.

  67. foxyshadis says:

    It can certainly win – by limiting its demographic appeal. :p

    Stern, I’ve noticed this too, from DOS to XP, in many programs, and I think it’s just evidence of keyboards or keyboard drivers routinely sucking. Some bit gets overridden and isn’t seen by the OS and poof, stuck key.

    I think we should all just go back to ctrl-k-m, ctrl-k-k, ctrl-k-c to select and copy things.

  68. Netchaser says:

    This is definitely cool

  69. kalleboo says:

    This is very logical and intelligent, and ever since 1990 when I used my first Mac it’s been exactly the behavior I’ve needed and expected – I have a hard time seeing how people can argue with it. Drag file from harddisk to floppy – of course I want to copy it! Drag file from one folder to another – of course I want to move it!

  70. Eh? says:

    Surly the last two methods are the other way round:…

    "If no modifiers are held down and the source and destination are on the same drive, then the operation is a move."

    Surly if ur dragging the file somewhere in the same location u’ll be creating a copy (even though this is also incorrect, without using any of the so-called modifiers I can only drag a file and create a copy in the same dir when I drag with the right mouse button, where I get a pop-up menu with the option to "Copy Here")

    "If no modifiers are held down and the source and destination are on different drives, then the operation is a copy."

    Surly this is the definition of a move, to drag the file from one location to another.

    I’ve attempted this on my PC and it seems to back me up, or does it owe me an apology, eh?

  71. Tom says:

    Heheheh… MS did a good job on UI design. The fact that so many people have different opinions on the way it works tells something about usability. This should be simple and obvious. "Normal people" are using computers too.

    Bad news is that it can’t be changed without upsetting a lot of people who have learned through the years to "understand" these rules. We’ll be teaching the future generations the same crap.

    The way Drag & Drop works together with the "single-click/double-click" rules crack me up. :-)

  72. RD says:

    MS -could- make the behavior modifiable… if someone wanted to force drag’n’drop to always be a copy… (and force moves to be done with a ‘modifier’ key) …then they wouldn’t have to worry about -accidentally- moving files or folders, especially when they’ve ‘slipped’ over some directory structure and then have to go hunting for the file/folders to undo whatever was done… or worse, not even know they’ve accidentally moved something. ‘Ctrl-Z’ undo is good to know (if you’re aware of your mistake)… although it prompts to delete (a copy), rather than undo it… that can be a scary prompt.

  73. Vito says:

    I think it’s more logical to force drag and drop to MOVE – everyone has a different opinion.

    I think it makes sense to leave the functionality the way it is and let the user change it via a control panel setting.

  74. RD says:

    Moving is a destructive behavior… copy doesn’t misplace anything. So a modifier key would make moving an explicit intent. As you said… different opinion.

    Control panel setting… that’s what I meant, a control somewhere to modify drag’n’drop behavior… a control which we don’t have now, as far as I know. No undocumented/registry hack?

  75. Raymond Chen says:

    Even if such a setting were added it wouldn’t affect all the other programs that do drag/drop. You end up with the situation "Well, if you’re dropping into Explorer it works this way, but if you’re dropping into Word it works that way, and if you’re dropping into Lotus Notes it works this other way," which is even worse since you can’t predict what’s going to happen any more.

  76. RD says:

    Not a Win programmer… so other programs don’t use a common Windows control, but they all adhere now to the same conventions? I admit I sometimes do filing during File, Open or Save dialogs, but I don’t know that the ‘general’ user does… Dunno why wouldn’t those other programs be using the generic Windows File open/save routines/dialogs… not that much code to optimize, is there? All I’m suggesting is the behavior of filing drag/drop. Other drag/drops, like associated program opening, printing, etc., are not filing ops, not concerned with move/copy. Maybe it would make other 3rd party file managers difficult though… but they customize the routines anyway.

  77. Snowdog says:

    I think it makes more sense to leave it like it is and not add anything to be able to change it. When I’m updating files on shared machines I sure don’t want to worry about my files getting moved off a network drive when I just drag them on machines A, B, and C but not X, Y, and Z. I can’t believe there is so much discussion around something that is pretty intuitive to begin with.

  78. It would create inconsistency with other programs.

Comments are closed.