none
System.IO.File.Move changes the files create details when moved across different machines (inconsistent with Windows Explorer) RRS feed

  • Question

  • Hi,

    When moving files in VB .NET code using System.IO.File.Move the following behaviour has been observed.

    * Moving within the same machine - file create and modify details remain the same as original values

    * Moving across machines - file create details changed to time of move while modify details remain the same as original values

    Using a DOS command manually, to move the file, and behaviour is the same as above. However, when using Windows Explorer the file create and modify details remain the same as the original values, even when moved between two different servers.

    Any ideas on why System.IO.File.Move does not behave in the same manner as Windows Explorer? For auditing reasons it would be best if a move did not alter the file creation details (ie. it worked the same as Windows Explorer).

    Thanks, Julie

    Wednesday, June 17, 2015 5:24 AM

Answers

  • "Moving within the same machine - file create and modify details remain the same as original values"

    AFAIK that isn't totally true - the create timestamp is only preserved when the file is moved to the same volume (partition). It is not preserved if the file is moved to a different volume even on the same machine. The reality is a true move can only be done on the same volume. In all other cases the move is really create new file, copy contents of the old file to the new file, delete the old file. Since a new file is created the create timestamp is that of a new file.

    "Any ideas on why System.IO.File.Move does not behave in the same manner as Windows Explorer?"

    The real question is why Window Explorer doesn't behave like MoveFile (the Win32 function that System.IO.File.Move uses).

    "For auditing reasons it would be best if a move did not alter the file creation details"

    I don't know what kind of auditing you are talking about but I wouldn't put much trust in file timestamp details. They can be changed at any time. In fact, you can change yourself the creation timestamp to match that of the original file (C# code, sorry, I don't know much VB):

    DateTime creationTime = File.GetCreationTimeUtc(source);
    File.Move(source, destination);
    File.SetCreationTimeUtc(destination, creationTime);
    

    • Marked as answer by juliew01 Thursday, June 18, 2015 12:24 AM
    Wednesday, June 17, 2015 5:49 AM
    Moderator

All replies

  • "Moving within the same machine - file create and modify details remain the same as original values"

    AFAIK that isn't totally true - the create timestamp is only preserved when the file is moved to the same volume (partition). It is not preserved if the file is moved to a different volume even on the same machine. The reality is a true move can only be done on the same volume. In all other cases the move is really create new file, copy contents of the old file to the new file, delete the old file. Since a new file is created the create timestamp is that of a new file.

    "Any ideas on why System.IO.File.Move does not behave in the same manner as Windows Explorer?"

    The real question is why Window Explorer doesn't behave like MoveFile (the Win32 function that System.IO.File.Move uses).

    "For auditing reasons it would be best if a move did not alter the file creation details"

    I don't know what kind of auditing you are talking about but I wouldn't put much trust in file timestamp details. They can be changed at any time. In fact, you can change yourself the creation timestamp to match that of the original file (C# code, sorry, I don't know much VB):

    DateTime creationTime = File.GetCreationTimeUtc(source);
    File.Move(source, destination);
    File.SetCreationTimeUtc(destination, creationTime);
    

    • Marked as answer by juliew01 Thursday, June 18, 2015 12:24 AM
    Wednesday, June 17, 2015 5:49 AM
    Moderator
  • Thankyou for your prompt reply.

    I have gone back to the client with your explanation and if it does become a huge issue for them I will just manually change the file creation date as you suggest.

    I must be old fashioned - it just seems wrong to be manually changing file creation and modify times :)

    Thanks, Julie

    Thursday, June 18, 2015 12:23 AM