sksbir Posted July 22, 2009 Share Posted July 22, 2009 (edited) Hello everybody I have a problem with creation date. This is not really an autoit problem, but more a windows problem. ( windows XP SP2, but perhaps other releases too) I made a autoit sample script to demonstrate what is the problem: this script creates and destroys 10 times the same file, and waits between creation and destruction. So the creation date should be always renewed, and should be the same ( or says : really close ) that the modification date. $FILEREF=@TempDir & "\TEST_" & @UserName & ".txt" ;;$FILEREF="D:\TEST_" & @UserName & ".txt" $TEXTE="Modification date<<<---->>>> creation date" for $CPT=1 to 10 If FileGetTime($FILEREF,0,1)<>FileGetTime($FILEREF,1,1) Then $TEXTE&=@crlf & FileGetTime($FILEREF,0,1)& "<>" & FileGetTime($FILEREF,1,1) EndIf filedelete($FILEREF) if FileExists($FILEREF) Then $TEXTE&=@crlf & "Problem : file still exists" Else $TEXTE&=@crlf & "File successfully deleted" EndIf sleep(1000) $DESC=FileOpen($FILEREF,2) for $CPT2=1 to 10 FileWriteLine($DESC,"TEST" & $CPT2) Next fileclose($DESC) sleep(1000) Next MsgBox(0,"results",$TEXTE) On my PC, the files keep their original creation date : how is it possible ?? somebody have a clue to get the creation date identical to the modification date ?? just deleting and recreating the file seems not to be the good method ( perhaps too simple, or too obvious? ) thanks in advance Edited July 23, 2009 by sksbir Link to comment Share on other sites More sharing options...
GEOSoft Posted July 22, 2009 Share Posted July 22, 2009 Just on a hunch I'm going to say that it's because of the Windows Disk Caching. If you delete the file and then restart Windows it shouldn't happen. Also there is rarely a need to check file Creation date, Last Modified is usually more pertinent to any file operations you want to perform. George Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number. Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else. "Old age and treachery will always overcome youth and skill!" Link to comment Share on other sites More sharing options...
sksbir Posted July 22, 2009 Author Share Posted July 22, 2009 Just on a hunch I'm going to say that it's because of the Windows Disk Caching. If you delete the file and then restart Windows it shouldn't happen. Also there is rarely a need to check file Creation date, Last Modified is usually more pertinent to any file operations you want to perform.Hello GEOSoftThank's for your reply.Comparing creation and modification date and check if they are the same is a good way to know if the file has been modified by hand since it's creation by my program.I want to check if somebody have modified the file, and if so, recreate the file to erase the unwanted modifications. Link to comment Share on other sites More sharing options...
sksbir Posted July 23, 2009 Author Share Posted July 23, 2009 (edited) hello back with even more weird behaviour: $FILEREF=@TempDir & "\TEST_" & @UserName & ".txt" ;;$FILEREF="D:\TEST_" & @UserName & ".txt" $TEXTE="Modification date<<<---->>>> creation date" for $CPT=1 to 5 $TEXTE&=@crlf & "1-FILEREF=" & FileGetTime($FILEREF,0,1)& "<>" & FileGetTime($FILEREF,1,1) filedelete($FILEREF) sleep(1000) $filenew=@TempDir & "\TEST_" & Random(1000,9999,1) & ".txt" $DESC=FileOpen($filenew,2) for $CPT2=1 to 10 FileWriteLine($DESC,"TEST" & $CPT2) Next fileclose($DESC) $TEXTE&=@crlf & "2-FILENEW=" & FileGetTime($filenew,0,1)& "<>" & FileGetTime($filenew,1,1) FileMove($filenew,$FILEREF,1) $TEXTE&=@crlf & "3-FILEREF=" & FileGetTime($FILEREF,0,1)& "<>" & FileGetTime($FILEREF,1,1) sleep(1000) Next ClipPut($TEXTE) MsgBox(0,"results",$TEXTE) result: Modification date<<<---->>>> creation date 1-FILEREF=20090723090326<>20090722221216 2-FILENEW=20090723090438<>20090723090437 3-FILEREF=20090723090438<>20090722221216 1-FILEREF=20090723090438<>20090722221216 2-FILENEW=20090723090440<>20090723090439 3-FILEREF=20090723090440<>20090722221216 1-FILEREF=20090723090440<>20090722221216 2-FILENEW=20090723090442<>20090723090441 3-FILEREF=20090723090442<>20090722221216 1-FILEREF=20090723090442<>20090722221216 2-FILENEW=20090723090444<>20090723090443 3-FILEREF=20090723090444<>20090722221216 1-FILEREF=20090723090444<>20090722221216 2-FILENEW=20090723090446<>20090723090445 3-FILEREF=20090723090446<>20090722221216 step1 : just checking date of fileref before deletion step2 : creating a new file, that NEVER existed before : creation and modification date seems to be OK... step3 : rename this new file in "fileref"--> this will return the creation date to the "original" creation date of fileref. well well, if somebody thinks this is a "normal" result, I'm curious to know why So the creation date of the file can be everything else that it is supposed to be, just because the filename existed before ? And the creation date of a file can change to something else when renaming it, just because the targed file existed before.... Is this an other "undocumented functionality" of windows ?? Edited July 23, 2009 by sksbir Link to comment Share on other sites More sharing options...
ResNullius Posted July 23, 2009 Share Posted July 23, 2009 See this article for some links to MS info that helps to explain this "feature" http://www.jroller.com/dschneller/entry/windows_date_created_timestamp_strangeness And this one suggests the solution is to explicity set the created time stamp when you create/recreate the file: http://www.devcity.net/Articles/133/1/article.aspx Link to comment Share on other sites More sharing options...
GEOSoft Posted July 23, 2009 Share Posted July 23, 2009 And what happens when you restart the computer between steps 2 and 3? That is BEFORE you rename the file. George Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number. Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else. "Old age and treachery will always overcome youth and skill!" Link to comment Share on other sites More sharing options...
sksbir Posted July 23, 2009 Author Share Posted July 23, 2009 (edited) See this article for some links to MS info that helps to explain this "feature" http://www.jroller.com/dschneller/entry/windows_date_created_timestamp_strangeness And this one suggests the solution is to explicity set the created time stamp when you create/recreate the file: http://www.devcity.net/Articles/133/1/article.aspx Thank's ResNullius, you've got it All I have to do is to add this line to my script: FileSetTime($FILEREF,FileGetTime($FILEREF,0,1),1) And what happens when you restart the computer between steps 2 and 3? That is BEFORE you rename the file. After following the links from ResNullius, I suppose that reboot will not change anything. Thank's anyway, the problem is solved for me Edited July 23, 2009 by sksbir Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now