How does the Move function work, exactly ?

Page 2 of 3 FirstFirst 123 LastLast

  1. Posts : 247
    Windows 7 Home Premium 64-bit (OEM)
    Thread Starter
       #11

    Yes ! Exactly ! Thanks, Layback Bear !
      My Computer


  2. Posts : 25,847
    Windows 10 Pro. 64/ version 1709 Windows 7 Pro/64
       #12

    Your most welcome.
      My Computer


  3. Posts : 6,285
    Windows 10 Pro X64
       #13

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


  4. Posts : 4,049
    W7 Ultimate SP1, LM19.2 MATE, W10 Home 1703, W10 Pro 1703 VM, #All 64 bit
       #14

    UsernameIssues said:
    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.
    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.
    Last edited by lehnerus2000; 14 Jan 2016 at 22:17. Reason: Additional
      My Computer


  5. Posts : 247
    Windows 7 Home Premium 64-bit (OEM)
    Thread Starter
       #15

    Ztruker said:
    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.

    lehnerus2000 said:
    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 ?
      My Computer


  6. Posts : 2,497
    Windows 7 Pro 64 bit
       #16

    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?
      My Computer


  7. Posts : 259
    Win7 sp1 Pro 64bit / XP sp2 Pro (games only)
       #17

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


  8. Posts : 721
    Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
       #18

    lehnerus2000 said:
    UsernameIssues said:
    Clairvaux 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.
    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.


    Wandering one said:
    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.


    Clairvaux said:
    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.
    Last edited by Pyprohly; 15 Jan 2016 at 05:46. Reason: Formatted, reworded and added information.
      My Computer


  9. Posts : 10,485
    W7 Pro SP1 64bit
       #19

    Wandering one said:
    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:

    How does the Move function work, exactly ?-move-file.png
      My Computer


  10. Posts : 247
    Windows 7 Home Premium 64-bit (OEM)
    Thread Starter
       #20

    Pyprohly said:
    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 ?
      My Computer


 
Page 2 of 3 FirstFirst 123 LastLast

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 03:59.
Find Us