Main Site Documentation

File's LastWriteTime changes EVEN when the file is simply opened and closed


Whenever a file is opened (even if the file is marked as ReadOnly and is only opened for READ access) the file’s LastCreated and LastModified change.

I’m using a Cerb board to test this. I think it’s a NETMF PK problem…

Here’s my code…

FileInfo fa = new System.IO.FileInfo(Program.CurrentFile);
DateTime actualWriteTime = fa.LastWriteTime;
fa = null;

Debug.Print("actualWriteTime: " + actualWriteTime.Ticks);

FileStream fs = System.IO.File.OpenRead(Program.CurrentFile);

fs = null;

FileInfo fa2 = new System.IO.FileInfo(Program.CurrentFile);
DateTime actualWriteTime2 = fa2.LastWriteTime;
fa = null;

Debug.Print("actualWriteTime2: " + actualWriteTime2.Ticks);

My results are:
actualWriteTime: 130341076940000000
actualWriteTime2: 130341933840000000

Clearly these values should be the same.


So I traced down all the code that might modify the write time. Turns out the FAT_LogicDisk.cpp’s FAT_LogicDisk::GetFile method updates the LastWrite time.

The Write method also does, so I just commented out the “dirEntry->Set_DIR_WrtDate” lines in the GetFile method. …Maybe this isn’t the best solution, but magically it works now!!!


I would report this on Netmf site.


Is that ?




@ untitled - That is interesting, I don’t have code n front of me now, but I wonder if the intent was not to set the last access time in GetFile.


I think the Open method always specifies CREATE_FILE.

Another bug, NETMF’s LastAccessed only stores the date, never the time. But before I think too hard, is that for a good reason? Am I missing some obvious reason why we wouldn’t want to store the time?


Wow, and System.IO.File.Move updates Created, Written and Accessed … why? A file is MOVED not changed. This info should be preserved right? Checkout FAT_LogicDisk.cpp’s Move method…

HRESULT FAT_LogicDisk::Move( LPCWSTR oldPath, LPCWSTR newPath )

    UINT32 oldPathLen, newPathLen;
    FAT_FILE srcFileInfo, destFileInfo;
    FAT_Directory* dirEntry;
    BYTE bytData[sizeof(FAT_Directory) - FAT_Directory::DIR_Name__size];

    TINYCLR_CHECK_HRESULT(FAT_Utility::ValidatePathLength( oldPath, &oldPathLen ));
    TINYCLR_CHECK_HRESULT(FAT_Utility::ValidatePathLength( newPath, &newPathLen ));

    dirEntry = GetFile( oldPath, oldPathLen, &srcFileInfo );

    //check src path legal

    // Store all the meta data, except the name
    memcpy( bytData, &dirEntry->DIR_Attr, sizeof(FAT_Directory) - FAT_Directory::DIR_Name__size );

    // Always create a file here, since we don't need it to allocate an extra cluster.
    dirEntry = GetFile( newPath, newPathLen, &destFileInfo, GetFile__CREATE_FILE | GetFile__FAIL_IF_EXISTS );


    // Copy the meta data from the temp storage
    memcpy( (void*)(&dirEntry->DIR_Attr), bytData, sizeof(FAT_Directory) - FAT_Directory::DIR_Name__size );

    UINT16 date,time;
    UINT8 timeTenth;

    FAT_Utility::GetCurrentFATTime( &date, &time, &timeTenth );

   // dirEntry->Set_DIR_CrtDate ( date ); //BS 1/14/14: Move should not change any of these dates.
   // dirEntry->Set_DIR_CrtTime ( time ); //BS 1/14/14: Move should not change any of these dates.
   // dirEntry->DIR_CrtTimeTenth = timeTenth; //BS 1/14/14: Move should not change any of these dates.
    //dirEntry->Set_DIR_WrtDate ( date ); //BS 1/14/14: Move should not change any of these dates.
    //dirEntry->Set_DIR_WrtTime ( time ); //BS 1/14/14: Move should not change any of these dates.
  //  dirEntry->Set_DIR_LstAccDate(date); //BS 1/14/14: Move should not change any of these dates.

    // Delete the old entry


Obviously I commented out that code on my version, I need that info to stay constant. My user’s view lists of files in folders on the SD card. They’re sorted by LastWritten, so the newest are on top.


@ untitled -

You’re right, at least move should not.


I do not believe this is a bug, originally FAT12 directory entries where defined as 32 bytes which persisted for FAT16 and FAT32, the compromise was made to store only the date for last access date.


Yup, only the accessed date (not time) is saved…