Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I ask a question a few days ago regarding the reason 7zip took so long perform a move on a large file after extraction.

After reading the FAQ, I discovered the issue was actually with Windows:

Only Windows Explorer knows exact drop target. And Windows Explorer needs files (drag source) as decompressed files on disk. So 7-Zip extracts files from archive to temp folder and then 7-Zip notifies Windows Explorer about paths of these temp files. Then Windows Explorer copies these files to drop target folder.

So, by default, even on the same hard drive, I assume Windows Explorer will copy a file (or files) from temp to the destination and then delete the temp file(s).

I assume Windows does this to maintain certain checks and balances. For instance, if user clicks cancel, what do you do if you're in the middle of a move?

Regardless, I would like to know if there is some configuration to change the behavior to make Windows move the file rather than copy/delete it?

share|improve this question
Have you made sure that this is actually what happens, and not just a documentation error? – Daniel Beck May 11 '12 at 13:29
Not a answer to your main question so I will leave this as a comment: "I assume Windows does this to maintain certain checks and balances. For instance, if user clicks cancel, what do you do if you're in the middle of a move?" For moves on the same drive windows just atomically just points the file to the new location in the directory structure, the data stays in the same place on the disk. When moving to a different drive, it actually just performs a copy then deletes the original when it is done, if the copy fails, it does not perform the delete. – Scott Chamberlain May 11 '12 at 14:39
@ScottChamberlain and Daniel..both points make sense.My OP makes an assumption based off of 7Zips documentation and my personal experience using "Drag and Drop" for 7zip. The RAR file was 7GB but, uncompressed, it was almost 60GB. Watching it uncompress was expected but then watching it copy from folder to another on the same drive was aggravating; only because I know I can move a 60GB file on the same drive all day long w/o delays. It's very likely I may not understand the true problem. – ray023 May 11 '12 at 15:37
Even though my folder and "temp" folder are on the same drive (D:) they are not on the OS Drive (C:) and maybe windows has to go through C: somehow to move the file? idk...I'll have to test it on another PC to find out if the same behavior happens on the same drive. – ray023 May 11 '12 at 15:38
Final note for myself: I tested "drag & drop" extract on my laptop (e.g. just a C:) and it was actually faster than drag & drop on my desktop. However, it was not as fast as "Extract Here" method mentioned in my first link; indicating to me that "drag & drop" on the same drive is not a "move" operation. I have a feeling my tests environments are not pure enough to make a sound deduction though. :P – ray023 May 14 '12 at 14:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.