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 12 hours ago 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 8 hours ago 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