Solved How does the Move function work, exactly ?

[Clairvaux]

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 ?

 

[UsernameIssues]

...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]

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.

 

[Clairvaux]

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.

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 !

 

[UsernameIssues]

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.

 

[Clairvaux]

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 ?

 

[UsernameIssues]

Sounds correct to me.

 

[UsernameIssues]

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

 

[Clairvaux]

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...)

 

[Layback Bear]

Clairvaux would this be what you are looking for?

http://www.sevenforums.com/tutorials/516-context-menu-add-copy-folder-move-folder.html

 

[Clairvaux]

Yes ! Exactly ! Thanks, Layback Bear !

 

[Layback Bear]

Your most welcome.

 

[Ztruker]

The big problem with Copy over Move to me is Copy changes the Create date, Move doesn't.

 

[lehnerus2000]

...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.

That is true if you are moving something within the same drive/partition structure.

It will take longer to move a file to a different drive/partition structure as new "index" records have to be created and the data has to be "physically" moved.

Presumably, the Storage Spaces feature of the W8 series and W10 will allow you to "move" files to any member (drive/partition) of the storage pool, by simply modifying the pool's "index" records.

 

[Clairvaux]

The big problem with Copy over Move to me is Copy changes the Create date, Move doesn't.

I hadn't realised that. On more reason to like Move.

I hate file dates in Windows 7. I still haven't mastered them. You have a thousand differently qualified dates, including a Date field with no added adjectives... I have taken to append my own date to every file I create a long time ago, and I still see no reason to abandon this habit. At least, I know this date will never change and I know what it means, which is more than you can say about Windows' dates.

One of the most horrible behaviours of the W 7 file system has to be the fact that a file can have been Modified before it was Created, which is counter-intuitive, to say the least.

I have come to believe that Date created (as well as some other Dates x) just means : date when Windows made something with this file, whatever that is. For all practical means, I find it useless.

It will take longer to move a file to a different drive/partition structure as new "index" records have to be created and the data has to be "physically" moved.

Thanks for confirming what I thought. So a Move operation to a different partition would actually copy the file on the destination and delete it from where it was ?

 

[LMiller7]

It is worth noting that move and copy handle the attributes of files and folders differently. These include compression, encryption, datestamp, and NTFS permissions. Generally with a move the file caries these attributes to the new location while with a copy they are inherited from the new parent folder.

Edit:

Thanks for confirming what I thought. So a Move operation to a different partition would actually copy the file on the destination and delete it from where it was ?

Yes. What else could it do?

 

[Wandering one]

I believe that when moving across partitions / drives, the file is deleted as it is being written in the new location. This is why I always copy and then delete manually. Found out the hard way if there is a problem in the process, sections of the file may be lost. Not too good working with video files.
Art.

 

[Pyprohly]

[...]

[...]
The file stays put.
The path to the file changes.

That is true if you are moving something within the same drive/partition structure.

It will take longer to move a file to a different drive/partition structure as new "index" records have to be created and the data has to be "physically" moved.

Precisely. We must realise that there are actually two distinct Move operations that Windows may perform, depending on whether a filesystem item is moved to another drive/partition or not.

For intuition, it's worth mentioning the applications of hardlinks. Hardlinks make it possible to have multiple references to a single physical file. That is, for instance, they allow for two separate directory entries to point to one physical space of data. Knowing this, a Move effect can be achieved by simply creating a hardlink to a file at a new destination then deleting the previous reference to that file.

E.g.,
Assume file C:\file.txt;
Create handlink to file.txt at new location C:\New\file.txt;
Delete file C:\file.txt.

The file C:\file.txt now resides in the directory of C:\New, just as if it were moved there.

I believe that when moving across partitions / drives, the file is deleted as it is being written in the new location.

In terms of a filesystem, if all it takes to delete a file is remove the file's reference, then why should a filesystem bother to erase a file's data when it's deleted? If it were the case that a file's data is overwritten upon deletion, then deleting a file would take just as much time as it took the file to get there. Furthermore, if a file's data is progressively erased as it is being moved, then interrupting the move operation will destroy the file. This would make for a very unstable OS.

I hate file dates in Windows 7. I still haven't mastered them. You have a thousand differently qualified dates, including a Date field with no added adjectives...

In Windows Explorer, the “Date” column is a calculated field. See this SuperUser answer. Regarding files under NTFS, the three fundamental dates, dates of which are actually recorded by the NTFS filesystem, are CreationTime, LastAccessTime, and LastWriteTime. All other dates you see in Windows Explorer are calculated, or are specific to certain file types.


Lastly, another piece of interesting trivia, if one is denied permission to delete a file they will also implicitly be denied from moving it. This is at no exception.

 

[UsernameIssues]

I believe that when moving across partitions / drives, the file is deleted as it is being written in the new location. This is why I always copy and then delete manually. Found out the hard way if there is a problem in the process, sections of the file may be lost. Not too good working with video files.
Art.

That should not happen.


I see that Pyprohly posted while I was gathering my data from Process Monitor. Pyprohly beat me to saying that the file is not deleted from its original location during a move (or during a manual "delete"). That is why "undelete" utilities have a shot at recovering files.

Notice when the original file was "deleted" from the desktop:

 

[Clairvaux]

In Windows Explorer, the “Date” column is a calculated field. See this SuperUser answer. Regarding files under NTFS, the three fundamental dates, dates of which are actually recorded by the NTFS filesystem, are CreationTime, LastAccessTime, and LastWriteTime. All other dates you see in Windows Explorer are calculated, or are specific to certain file types.

Fascinating, Pyprohly. So I'm not the only one befuddled about those "dates". I've been using W 7 for 5 years, read whole W 7 books, browsed an untold number of help sites and Microsoft sites, and it's the first time I come across this fundamental piece of information.

This will make me stick more than ever with my resolution to append my own creation dates to my own files...

Does CreationTime = Date created, LastAccessTime = Date accessed and LastWriteTime = Date modified ?

Would you be aware of a help page somewhere about dates in Windows Explorer ? Something user-oriented, not overly geeky ?