Sign in to follow this  
Followers 0
sksbir

[Solved] Recreated files keep their previews creation date!!

7 posts in this topic

#1 ·  Posted (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 by sksbir

Share this post


Link to post
Share on other sites



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!"

Share this post


Link to post
Share on other sites

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 GEOSoft

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

Share this post


Link to post
Share on other sites

#4 ·  Posted (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 by sksbir

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!"

Share this post


Link to post
Share on other sites

#7 ·  Posted (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 by sksbir

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0