In theory, the "File Created" time refers to when a particular node of data in the file system is created. The values of this data (file contents) and the path to this data (file name/location) are irrelevant. Thus, renaming a file won't change its create date, nor will editing the file. For that matter, creating a hardlink to a file (which creates a new pathname pointing to the same data on disk) will cause the hardlink to have the same creation date as the original; it's another way to access the same node, and the node's creation time hasn't changed. On the other hand, making a copy of a file will put the current time as the creation date of the copy (because the copy is stored in a different location on the disk), and moving a file across file systems (for example, from a flashdrive to an internal drive) will also change the creation time (unless the utility that does the move restores the original time) because the destination file system must create a new node for the arriving file.
Finally, if you delete a file and then create it again, it should get a new creation time. After all, the new file was literally created just a moment ago, and doesn't map to any pre-existing data in the file system. Indeed, this will happen... if you wait long enough between deletion and re-creation.
However, sometimes file creation times don't get updated when you expect them to. In particular, when one file is deleted or renamed, and another is created or renamed to have the old name, the creation time of the first file is applied to the second. This somewhat-bizarre feature in Windows is for compatibility with an old DOS technique for "safely" modifying a file, whereby the new data was written to a temp file, the original was deleted, and the temp file was renamed to the original's name. To support this, Windows will by default remember file creation times for some period (30ish seconds?) after a file is deleted or renamed. You can find more information about it here: https://support.microsoft.com/en-us/kb/172190
Most of your image links are non-op. I suppose that by "overwriting" files, you mean changing the contents, even perhaps all of the contents. But that is not "creating" a new file. It is just changing the contents of an existing file, and therefore the Date Created attribute should not change. I have no idea what you mean by "GUID constraint", perhaps you should reword that. – kreemoweet – 2015-09-02T19:34:53.133
@kreemoweet space added for images 3-6 because I cannot include more than 2 links at 3 rep. Hoping for a courteous editor to come along and clean up the post since I am restricted. for the time being, please just remove the space to get the actual link. GUID - Globally Unique Identifier – Peter Vandivier – 2015-09-02T19:37:59.670
1Please explain why you added those images. I don't see how they are related to your question. Pick one image – nixda – 2015-09-02T22:03:52.787
@nixda the pictures show the aberrant behavior in sequence as I describe in two contexts. Not sure how to do that in one image but you are welcome to edit down to a single image if you can think of a way to do this – Peter Vandivier – 2015-09-02T22:07:16.640