Jump to content

File creation dates set to file modified date

Recommended Posts

Version Citing files created in Data CD option have their file creation dates set to the file modified dates, differing from source. Using Windows XP SP3 NTFS. A 25 cent error for free software but still something to consider.

Link to post
Share on other sites
  • 1 month later...

I'm having a similar problem (or possibly identical) - and it seems to have been reported by epgeek on 7 Jan 2011 as well.

I am using v., mainly for a weekly backup job which I have saved as a .dxp. After burning, CDBurner verifies the disc, and when I ran it today it reported no errors.

However, I am currently evaluating two file/folder comparison utilities that I've just installed (ViceVersa and SwiftCompare), and they reported a difference between the source files and those on the CD. On closer inspection, the content of the files was actually identical, and the difference was only in the dates. I haven't analysed the files in detail to see if these dates were when they were created or an earlier modification, but it still seems that something is wrong. As far as I can see, modified date should be what it says.

I couldn't see anything about this in the changelog, but is it something that's been fixed since v.2356? And if not, is it on the to-do list?


Link to post
Share on other sites

I've now looked into the dates a bit more, and I can add a little to my earlier post:

It seems that the Modified date that's being recorded on the CD is the one that would have been correct on the previous occasion that the job was run. So, for example, I have a file that was modified on 23 May and 14 June. I ran the backup job on 12 June, and again today (19 June). The version on the hard disk (source) correctly shows that it was last modified on 14 June, but the one on the CD says it was last modified on 23 May. Nevertheless, the contents of the file on the CD are identical to the HD (14 June) version, and accurately reflect the changes that were made on 14 June.


Link to post
Share on other sites

After a bit more testing I've discovered the following:

My usual workflow was to let the weekly backup job update the compilation, then I would save it and finally run it. This produced the date errors I mentioned before. This time, after the compilation was updated I saved it as normal, but then I closed it. I then reopened it and ran it, and there were no date errors. From this it seems that the details of the job (specifically the files' last modified date and time) are not fully updated/saved until the job is actually closed.

Please can anyone say whether this is the intended behaviour, or something that needs fixing?


Link to post
Share on other sites
  • 2 weeks later...

I am also seeing incorrect file date/time on some files written to a CD or DVD with the latest version of CDBurnerXP.

This makes updating only changed/new files using multi-session problematic.

The bug might be related to file times created while in standard vs daylight savings time as well.

I hope this problem can be resolved in the next version to allow for multi-session file backup updates to work correctly.

Also some suggestions for new features to make multi-session file backups even easier:

add feature to link source folders to multi-session folders for quick updating, remove and add differing files in tree.

add feature option after burning compilation to clear archive bits of source files

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.