New file, old date. ¯\_(ツ)_/¯

[argumentum]

expandcollapse popup

#include <Date.au3>

Global $dbg = StringTrimRight(@ScriptFullPath, 4) & ".log"

FileBkupRename($dbg)
Func FileBkupRename($sFilename)
    If Not FileGetSize($sFilename) Then Return
    Local $sFileTime = FileGetTime($sFilename, 1, 1) ; $FT_CREATED (1) = Created ; $FT_STRING (1) = return a string YYYYMMDDHHMMSS ;
    Local $sFileNoExt = StringLeft($sFilename, StringInStr($sFilename, ".", 0, -1) - 1) ; $FT_MODIFIED (0)
    Local $sFileExt = StringTrimLeft($sFilename, StringInStr($sFilename, ".", 0, -1))
    Local $iAdd = Asc('a'), $sNewFilename = $sFileNoExt & '.' & $sFileTime & '.' & $sFileExt
    While FileExists($sNewFilename)
        If $iAdd > Asc('z') Then ExitLoop
        $iAdd += 1
        $sNewFilename = $sFileNoExt & '.' & $sFileTime & Chr($iAdd) & '.' & $sFileExt
    WEnd
;~  ConsoleWrite('-     $sFileTime >' & $sFileTime & '<' & @CRLF)
;~  ConsoleWrite('-    $sFileNoExt >' & $sFileNoExt & '<' & @CRLF)
;~  ConsoleWrite('-      $sFileExt >' & $sFileExt & '<' & @CRLF)
    ConsoleWrite('-  $sNewFilename >' & $sNewFilename & '<' & @CRLF)
    If Not FileMove($sFilename, $sNewFilename) Then
        ConsoleWriteDbg('! failed to FileMove("' & $sFilename & '", "' & $sNewFilename & '")' & @CRLF)
    EndIf
EndFunc   ;==>FileBkupRename

Func ConsoleWriteDbg($sStr)
    Local Static $iDoThaThing = 1
    If $iDoThaThing Then
        $iDoThaThing = 0 ; do not "Do Tha Thing" again !
        Local $hFileOpen = FileOpen($dbg, 2) ; $FO_OVERWRITE (2) = Write mode (erase previous contents)
        FileWrite($hFileOpen, "")
        FileClose($hFileOpen) ; the fix is to FileSetTime() the "creation" timestamp, as otherwise it will be the prior's file timestamp !?
        FileSetTime($dbg, StringReplace(StringReplace(StringReplace(_NowCalc(), "/", ""), " ", ""), ":", ""), 1) ; $FT_CREATED (1) = Created
    EndIf ;    If the time is blank "" then the current time is used. I know.
    ConsoleWrite($sStr)
    FileWriteLine($dbg, @CRLF & _NowCalc() & @CRLF & $sStr)
EndFunc   ;==>ConsoleWriteDbg

ConsoleWriteDbg("- Loaded at " & _NowCalc() & @CRLF)

...so, am like: "I'll rename the old log to the created timestamp and create a new one. Great idea !"
Then the filemove/rename fails, and am like,  "hmm, I'll add a letter to make it unique if it fails. Great  idea !"
..and each file has a new letter: b, c, d, e, f, .. and am like "WTF !"

The guilty party is the OS. How do I know that is the OS ?, simple:  echo . >_FileBkupRename_Test.dbg   does that too.
Why would the OS do that !.

The solution: set the creation timestamp on file creation to have the timestamp corresponding to the time of creation    ¯\_(ツ)_/¯

PS: just sharing. If it happens to you, now you know, you're not alone.

Edited Tuesday at 05:32 AM by argumentum

[rudi]

I'm not really sure if I get your question.

But I can confirm, that this behavior of the OS Windows is a matter of fact:
 

1. There is a given file with the original data. There are three timestamps associated with this file object: CreationTime, LastAccessTime, LastWriteTime. I never make use of "lastaccesstime", so the rest of this writing is just about creation an write time.
2. When you *MOVE* the file within the same *DRIVE*, the timestamps are preserved. The reason is, that the file is physically moved, it is the same file after the move
3. When you copy a file, then a new file is created, preserving the timestamp LastWriteTime, but receiving a new timestamp for CreationTime = "point-of-time-of-the-copy-process"
4. When you move a file crossing drive borders, then physically the "move" is done in two steps. Step 1: The file is copied to its new location. Step 2: The original file is deleted afterwards. so the resulting time stamps end up in the situation I described for "when you copy a file". Note: If you connect two different drive letters to the same share,  eg. letter F: and G:, and "move" a file from F: to G:, then this will be a "copy-and-delete-original" action.

 

IMHO you need to "transfer" the original timestamp for "CreationTime" manually, when you copy a file and want the new one to reflect the original timestamp.

<edit> Note: There is a purely client side registry key, that will enforce a "always-do-a-copy" for network drives. The reason this one was introduced is the dumb fact, that moving a file within one network drive will also move the file's ACL (access control list) with the file. Often ending up in unpredictable access situations. (I moved the file to <folder xy you have access to>: you *MUST* see it now -> no, I don't see it!)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer

Name:          MoveSecurityAttributes  
Type:          REG_DWORD  
Value:  
    0 = Default behavior (security attributes are preserved)  
    1 = Security attributes are **not** preserved when moving (copy-then-delete behavior)

 

Edited Tuesday at 09:24 AM by rudi

[argumentum]

5 hours ago, rudi said:

I'm not really sure if I get your question.

I didn't make a question. It was a warning of the creation time on a new file.
As far as I remember, if I make file A and rename it B, it keeps all the creating/mod times.
If I make a new A file it should not have the creation time of the now B file because, is unrelated other than having the same name the other had once before.

Maybe I should reboot and see if it keeps happening. Or, turn it off and go on a vacation 🤪

But thanks for sharing these things I wasn't aware of  

[rudi]

I cannot see, that adding content or renaming a file by means of the windows OS is messing up the creation timestamp:

 

PS C:\temp> "test" | out-file "test.txt"
PS C:\temp> gci .\test.txt


    Verzeichnis: C:\temp


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        31.07.2025     16:48             14 test.txt


PS C:\temp> gci .\test.txt | ft creationtime,lastwritetime,length,name

CreationTime        LastWriteTime       Length Name
------------        -------------       ------ ----
16.12.2020 14:10:46 31.07.2025 16:48:35     14 test.txt


PS C:\temp> $file=gci .\test.txt
PS C:\temp> $file.CreationTime = $(Get-Date).date
PS C:\temp> gci .\test.txt | ft creationtime,lastwritetime,length,name

CreationTime        LastWriteTime       Length Name
------------        -------------       ------ ----
31.07.2025 00:00:00 31.07.2025 16:48:35     14 test.txt


PS C:\temp> "line2" | out-file "test.txt" -Append
PS C:\temp> gci .\test.txt | ft creationtime,lastwritetime,length,name

CreationTime        LastWriteTime       Length Name
------------        -------------       ------ ----
31.07.2025 00:00:00 31.07.2025 16:50:50     28 test.txt

PS C:\temp>
PS C:\temp> $TS=$(get-date -format "yyyy-MM-dd_hh-mm_LOG")
PS C:\temp> $ts
2025-07-31_04-57_LOG
PS C:\temp> $newname = $file.name + "_" + $TS + ".backup"
PS C:\temp> move .\test.txt $newname
PS C:\temp> gci $newname | ft creationtime,lastwritetime,length,name

CreationTime        LastWriteTime       Length Name
------------        -------------       ------ ----
31.07.2025 00:00:00 31.07.2025 16:50:50     28 test.txt_2025-07-31_04-57_LOG.backup

 

[argumentum]

2 minutes ago, rudi said:

I cannot see..

And right you are. You shouldn't see it happen. It should never happen !, yet, call it what you will, it happened to me and if anyone said that it happened to them I'd think that they are on mushrooms or something, because is not the way it goes yet, it happened to me.
This thread is more of a "watch out" than rant or anything else. And I do thank you for trying to figure it out, but it just shouldn't happen 🤷‍♂️