Until reading this question I had never even considered using Copy & Paste. That was always something one did with text or pictures within files. I truly didn't know that would work with file manipulation. Hah, learn something new every day. I used COPY in DOS, and went straight to Drag & Drop in Windows.
A file's Date-Created date should, surely, be immutable, but Windows 7 clearly disagrees.
If the creation date of any file is important to you, then that information absolutely must be incorporated into the body text of the file itself, or included in the file name.
Including the date in the filename as, 20090921Letter.doc, (YYYYMMDD, 21st September 2009, UK order) lists files in date sequence when Sort By Name is chosen in Explorer, alternately ascending and descending following subsequent use of Sort By Name. And, of course, Windows 7 will append (2), (3), (4) etc., to files with the same name. (NOTE: using DDMMYYYY does not sort in correct, sequential date order.)
Retrospective renaming of many individual files would be tedious, but there are many bulk file renaming programs which may allow renaming with added date string in this way. I've not tried any, but can't see what use they'd be if they couldn't do this.
Using YYYYMMDDfilename.ext is actually a useful convention, and is worth adopting by anyone when creation date is very important. Though we could use the date digits in DOS filenames, there was no room for any other text in the filename. But, then again, DOS got the Date fields right so we didn't need it.
I have no idea what the outcome regarding Sort order would be using the US date convention of YYYYDDMM, I only know, by trial, that DDMMYYYY (UK) doesn't work properly.
Drag and Drop can be used to either Copy OR to Move by use of the Ctrl OR Shift keys following selection, or, depending on circumstances, a Link might be offered instead. (This in response to rcj007.)
The following is what I discovered when I first noticed this quirk of 7's some time ago, and only offer it for interest. I actually spent a fair bit of time messing about with file dates, and made notes.
Date, Date-Last-Saved and Date-Modified are always the same.
Date-Created often shows a later date than Date-Last-Saved, which is, of course, impossible without a Flux Capacitor and a DeLorean. This indicates that 7 is giving the file's Date-Created date as when it was simply MOVED or COPIED from one location to another, and not its true creation date. (I have many unrelated groups of files showing the same Date-Created, which confirms such movement - when I did a bit of housekeeping and moved files around into other folders.)
Date-Accessed does not change when the file is opened and closed, only when it's been opened and subsequently saved, which in my opinion is wrong - accessed means what it means - and then only Date-Created remains the same, which could well already be meaningless anyway.
Examples: (DL=DateLastSaved, DC=DateCreated, D=Date, DA=DateAccessed, DM=DateModified.)
True date of creation of the test file was 25/11/2010 (25th Nov 2010, UK order). The file is a letter which contains that date within its text.
How 7 presents it:
At this point, none is actually correct, but DL, D, and DM are close, and include the few days spent in final editing before the final save and send to print.
DC is already way off target, and is actually the date I moved the file to its new directory. DA seems always to be guesswork, and I absolutely know I didn't access it last New Year's Day.
After modifying and saving, or just saving (I tried both) on 22/04/2012:
And now not a single date offered is anywhere near the file's actual creation date (25/11/2010). Those dates that previously came close have now changed into nonsense.
If this system is followed at Win7's Search level then its Modified-by-Date Search function is likely useless. And how this will affect any Backup procedure, which will likely rely heavily on date, is anybody's guess. Of course, it is entirely possible that Windows maintains dates at system level correctly, and only user presentation is skewed.