How does the Move function work, exactly ?

I've been trying to move around a lot of files lately. I've mostly used the Copy function at first (or third-party copy tools with hash verification), thinking it was the safe way.

Then, I experimented with the Move function, and I was surprised to find that it works with no delay at all, even if there are tons of files involved (provided, I think, that one remains within the same partition or disk).

I assumed that it is because it does not change anything to the file itself, but only tells Windows : this file used to be here, now it's there, just change the path.

I also assumed that, beyond being much faster than Copy, it's also safer, since it does not have to create the file all over again, so no corruption can happen.

And therefore, that it should be preferred when moving a large number of files.

Is that correct ?

Clairvaux said:

...this file used to be here, now it's there, just change the path.

I also assumed that, beyond being much faster than Copy, it's also safer, since it does not have to create the file all over again, so no corruption can happen.

And therefore, that it should be preferred when moving a large number of files.

Is that correct ?

For the move function:
(like you said)
The file stays put.
The path to the file changes.

The file might not get corrupted during a move, but (on rare occasions) recording the new path can fail and the file can be "lost" that way.

Layback Bear said:

I don't move things around much but when I do I prefer (Copy) rather than (Move)

The reason is when you copy from "A" to "B" you can verify the copy on "B" is correct before removing it from "A".

Just a thought.

That was the logic I initially followed.

UsernameIssues said:

The file might not get corrupted during a move, but (on rare occasions) recording the new path can fail and the file can be "lost" that way.

So, not entirely foolproof after all... too bad.
Thanks !

I have never seen a file move fail in Windows 7. I have seen it fail a long time ago on an older OS.

I would think that a power outage at just the wrong moment could make a file move fail on any OS.

UsernameIssues said:

I have never seen a file move fail in Windows 7. I have seen it fail a long time ago on an older OS.

Thinking of it, all those remarks might tend to validate the Move option in a case similar to mine.

That is :

• I have a backup of all my documents that I am about to restore.
• I want to change my folder structure to keep up with my needs.
• Some files and folders are better not restored, but kept as archives.
• I restore the whole folder structure as it was, using Macrium (which verifies upon restore).
• I use the Move function to arrange files and folders in the new structure.
• I can move gigabytes in no time at all, since the files themselves don't... move.
• In the unlikely event that the move fails and my files go poof !, it's no big deal because I still have that backup.
• I suppose that files might then be all over the place on my disk, but that would be corrected at the next scheduled defrag.

Correct ?

Sounds correct to me.

Layback Bear said:

I don't move things around much but when I do I prefer (Copy) rather than (Move)

The reason is when you copy from "A" to "B" you can verify the copy on "B" is correct before removing it from "A".

Just a thought.

Have you ever renamed a folder that had files in it? If so, then that is a "move".

There are times when I copy/paste/check/delete...
...but I move a lot too

By the way, stupid Windows 7 does not have a right-click option for the Move function . (I know there's a magic little download to correct this, somewhere in Seven Forums...)