There is an API to modify an NTFS's file "creation time" - so it could be that although Windows has the "creation time" concept, it is not guaranteed that the time you get is really the "creation time" as anybody with the appropriate permissions could have modified that time! Whoa!

Access to the Windows "creation time" requires the Win API and is not part of "standard Perl".

So: some file systems track "creation time". Unix file systems are not one of them. Normally the "last modified" time is sufficient. And that's a good thing as that is all Perl allows you to get to with the standard built-in functions. But as a "nit" here, I point out that some filesystems do track creation time.

I think that the OP would do well by measuring the shortest of these parameters:
-M Modification age (measured in days)
-A Access age (measured in days)

If you haven't read a file or modified it within X days, then I would say that it is a "candidate for deletion". Under this kind of a test, I don't see how when the file was originally created makes a difference. If it not being used or modified, then who cares? Implement something like the Windows Trash Folder. Instead of deleting a file outright, move it there and wait for Y days to see if anybody really misses it! If you don't get any complaints, then do a final deletion.

Different file systems have different ways of dealing with "creation time". Normal Unix file systems do not have a concept of creation vs modification time at all. You can only get "last modified" time. Windows NTFS does have the concept of: creation time, last accessed time, and last modification time. see (sic) ...

If I am reading your statement correctly, you are saying that the ctime, mtime, and atime do not exist under the historical unix file system inode. Is this correct?

So: some file systems track "creation time". Unix file systems are not one of them. Normally the "last modified" time is sufficient. And that's a good thing as that is all Perl allows you to get to with the standard built-in functions. But as a "nit" here, I point out that some filesystems do track creation time.

I can concur with that. Reference: "the ctime test may actually return the creation time". I would, however, ask what creation time signifies. What happens when a file is restored? Does the attribute follow on a copy? How about when the method of saving a file is "save new, rename old, rename new, remove old"?

I think that in the context we are discussing (OP's question), these concepts are for the most part equivalent.

Update:

Cleaned up my thoughts and wording

--MidLifeXis

The "modification time" and "last accessed time" work the same on Unix and Windows and these two times are normally sufficient for doing whatever is needed. I would suggest staying away from ctime because it is a bit different between Windows and Unix.

I would, however, ask what creation time signifies. What happens when a file is restored? Does the attribute follow on a copy? How about when the method of saving a file is "save new, rename old, rename new, remove old"?

Creation time would be the time when this file first "came into being". Basically that means it is a constant generated at file creation. It could be that there is some ancient Windows file that is many years old but which gets changed and accessed a lot! If you copy a file (or restore it), the creation time follows it. If you go through the sequence you asked about, file "new" will get a creation time of "right now" because it is literally a "brand new file". The more recent version of file "old" will wind up with that creation time of file "new" instead of whatever date the original file "old" had.

The name in the directory is just a way for a human readable set of bits (the name) to be associated with some set of data bits on the disk. That look up in the directory is what happens when you do an "open file". Once you have opened a file, the name is irrelevant, the file handle is essentially a pointer to a structure that describes the file...how big it is, what physical disk block it starts on, and other attributes like modification time, etc. All that stuff exists independent of the "name".

I hoped this helped rather than further confusing things.