"Date Created" doesn't change after Copy/Paste


  1. Posts : 116
    Win 7 x64 Professional
       #1

    "Date Created" doesn't change after Copy/Paste


    I've found a strange situation where the directory field "Date Created" does not change after a copy/paste using Windows Explorer.

    Here's the scenario:

    1) Image files are written to a folder on the hard drive from an SD card.

    2) "Date Modified" shows the time/date the photo was taken, as written by the camera. "Date Created" is the time/date the photos were copied from the SD card to the folder on the hard drive.

    3) A file is opened from this folder into a photo editor and modified.

    4) The modified image is written to a DIFFERENT folder.

    5) On the new/modified image, "Date Modified" is still the original time/date the photo was taken. "Date Created" is now the time/date the new image file was written by the photo editor.

    6) I now have two different image files in two different folders. One (A) is the original, the other (B) is a modified copy.

    7) "Date Modified" on "A" and "B" are the same. "Date Created" on "A" and "B" is different.

    8) The modified image is copied to the image in the original folder using Copy/Paste operation Windows Explorer. The "overwrite" warning clearly shows the file has changed in size. A "Yes" indication is given. The file copies.

    9) The file in the original folder now shows the new size.

    10) After I have performed the copy operation, I find the the "Date Created" field HAS NOT CHANGED (it still shows the time/date that was on "A", not "B"), yet the file size HAS changed indicating a copy of "B" content actually took place and overwrote "A".

    11) I also notice the thumbnail image does not reflect the edited changes, it still shows the original file. However if you open the file for viewing, the changed image is there.

    This is causing problems with my backup. The modified files are not getting backed up again as "changed", apparently because the "Date Created" field hasn't changed.

    So, why doesn't "Date Created" changed after the copy/paste? Why is it keeping the value of the original file and not the one that overwrote it?

    Is this an indexing issue? How can indexing be forced if that's the case? (I already tried hitting F5, nothing).

    Is this a Windows 7 bug? If not, what's the logic for this? Makes no sense, and it's causing problems.
      My Computer


  2. whs
    Posts : 26,210
    Vista, Windows7, Mint Mate, Zorin, Windows 8
       #2

    I don't have this problem. The "date created" changes to the current date and time with both Copy/Paste and Copy to folder. Did you check this in Properties > Details.
      My Computer


  3. Posts : 1,170
    XP Pro SP3 X86 / Win7 Pro X86
       #3

    Jeffs said:
    I've found a strange situation where the directory field "Date Created" does not change after a copy/paste using Windows Explorer.

    Here's the scenario:

    1) Image files are written to a folder on the hard drive from an SD card.

    2) "Date Modified" shows the time/date the photo was taken, as written by the camera. "Date Created" is the time/date the photos were copied from the SD card to the folder on the hard drive.

    3) A file is opened from this folder into a photo editor and modified.

    4) The modified image is written to a DIFFERENT folder.

    5) On the new/modified image, "Date Modified" is still the original time/date the photo was taken. "Date Created" is now the time/date the new image file was written by the photo editor.

    6) I now have two different image files in two different folders. One (A) is the original, the other (B) is a modified copy.

    7) "Date Modified" on "A" and "B" are the same. "Date Created" on "A" and "B" is different.

    8) The modified image is copied to the image in the original folder using Copy/Paste operation Windows Explorer. The "overwrite" warning clearly shows the file has changed in size. A "Yes" indication is given. The file copies.

    9) The file in the original folder now shows the new size.

    10) After I have performed the copy operation, I find the the "Date Created" field HAS NOT CHANGED (it still shows the time/date that was on "A", not "B"), yet the file size HAS changed indicating a copy of "B" content actually took place and overwrote "A".

    11) I also notice the thumbnail image does not reflect the edited changes, it still shows the original file. However if you open the file for viewing, the changed image is there.

    This is causing problems with my backup. The modified files are not getting backed up again as "changed", apparently because the "Date Created" field hasn't changed.

    So, why doesn't "Date Created" changed after the copy/paste? Why is it keeping the value of the original file and not the one that overwrote it?

    Is this an indexing issue? How can indexing be forced if that's the case? (I already tried hitting F5, nothing).

    Is this a Windows 7 bug? If not, what's the logic for this? Makes no sense, and it's causing problems.

    I think WHS is on the right track...
    In "Thumbnail" view the information displayed is actually metadata extracted from the file itself whereas in Detail view it's using file system dates.

    Why this would affect your backup is good question... Do you have the option of triggering backup based on the "Archive" file attribute... This is a directory flag that is set any time a file is changed in any way.
      My Computer


  4. Posts : 116
    Win 7 x64 Professional
    Thread Starter
       #4

    @WHS,

    Yes, I've checked this with Properties>Details, although it shows on the General tab too.

    @CommonTater,

    OK, that would explain why the thumbnail doesn't change since it's the EXIF thumbnail written by the camera at the time of the shot.

    Backup is with JungleDisk. Yes, one would think the archive flag would be used for backup. Something is definitely wrong though, since the updated files do not back up again, and I have a message in to them as well.
      My Computer


  5. Posts : 1,170
    XP Pro SP3 X86 / Win7 Pro X86
       #5

    Jeffs said:
    Backup is with JungleDisk. Yes, one would think the archive flag would be used for backup. Something is definitely wrong though, since the updated files do not back up again, and I have a message in to them as well.
    I've not used jungle disk so I'll have to defer to the others, perhaps some of them have... But just one final note to double check the settings in that program. Programmers don't always put options where we think they should be.
      My Computer


  6. Posts : 116
    Win 7 x64 Professional
    Thread Starter
       #6

    As a follow up, I've discovered what the source of the problem is. It isn't Windows cut/paste, but a utility program that's doing (in my opinion) incorrect file dating operations.

    I use a GPS recorder when I go out on photo shoots, so I can geotag the images. The program I'm using is an open source utility called GPICSYNC. When I take my original images from the SD card and dump them onto the hard drive, File Created date is that of the time/date of the copy. The Date Modified is that of when the photo was shot.

    Assume the files get backed up at this point.

    At this point I take an image into an editor, modify it and write it to a new folder. It's Date Created, Accessed, and Modified are all the same, and are the time/date this file was just written out. This file also has a different size than the original.

    Now, on this modified image I run GPICSYNC to do the geotag operation. When complete, GPICSYNC has done a "reverse touch" on the Date Modified and Date Accessed and set them backward to the time/date that the picture was taken. If I now do a copy/paste of this modified file and copy it over the camera original, Windows warns me the file has changed (size) and does the copy. However the file has the same Date Modified that it did when it was first backed up, because GPICSYNC did a reverse touch on the dates when it geotagged them. Even though the file has changed and it's size is different, Jungledisk doesn't back it up again as "updated" apparently because the date modified hasn't changed. If I do a regular "file touch" on this file to make it today's date, Jungledisk will do an update backup.

    So the culprit appears to be GPICSYNC, although I still feel that Jungledisk should back the file up anyway. I don't know yet exactly what their trigger to backup a file is. I've got a support case open, and I'm still waiting to hear back from them.
      My Computer


  7. Posts : 2
    win 7
       #7

    I have 3 folders if I move folders to new location , date created and date modified do not change, but if I copy folders to new location both data created and date modified change to current time.
    Why data created is not same as original folder's date created?
    In that way very important information is lost!
    How can I change this behavior?
      My Computer


  8. Posts : 2
    win 7
       #8

    I zip 14 (2G) folders with photos to preserve date created, then I extracted them in to new location.
    Windows zip extracted only 4 folders.
    I checked zip file, it is ok and it include 14 folders with photos.
    Date created changed to current time but date modified do not.
    Now I have folders with date modified before date created.
    This is incorrect and I'm
      My Computer


  9. Posts : 9
    Win 7, 64bit
       #9

    Isn't that completely backwards?

    Date Created should be the date the PICTURE was originally taken on the camera.
    Date Modified would be the date of the last file operation.

    In fact I am trying to figure out an opposite problem. Something on my computer keeps changing the Date Created to the current day regardless of whether I did an operation with the pictures or not.
      My Computer


  10. Posts : 10
    Windows Home Premium 64Bit
       #10

    It's a Bill Gates Brainfart that's...


    It's a Bill Gates Brainfart that's been with us since Win 98/ii, afaik.

    It would have been better if they'd just gotten rid of Created Date altogether. Linux doesn't bother with it.

    And this might be a smidge OT, but I'd like to warn Windows 7 users about the NirSoft utility NirCmd. Its "setfiletime" will remove "Date" in Explorer but make it look like you did a touch (ie, set the item's modify date to the current date and time) in its Properties window. I recommend staying away from it and sticking to the GUI date attribute changers.

    Just my 60 cents.

    BZT
      My Computer


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 14:57.
Find Us