Jump to content

Retrospect execution errors


slowMX5

Recommended Posts

Running Retrospect 7.6.

 

When running Duplication scripts I am getting execution errors such as this:

File "E:\Pictures\2009\IMG_1172.JPG": different creation date/time (src: 01/10/2009 17:12:06, dest: 01/10/2009 17:45:02)

 

I am getting these for music, video and picture files. I can't see how something which has been duplicated can have different creation times? I have even copied the duplicated files back to the source file (over writing the source contents) and then tried again but I still get the same execution errors? Anyone know what is going wrong? It is not only driving me nuts getting all the errors but it is also resulting in long duplication times due to the 'apparent' file mis-match.

 

Steve.

 

Link to comment
Share on other sites

Thanks.

 

OK upgraded to 7.7, I still have the execution errors. Some of the duplicate files continue to have newer creation times. Very odd, but does seem to be restricted to photos or videos I have edited at some time in the past, although why the time would be different on the duplicates I do not know - especially after I copied the duplicates back to the source file over writing the originals before running duplicate again (twice). For the music files copying back to the source from to the duplicate did sort the problem. Not only that but I also tried copying the offending files to a separate folder manually and they had the same, changed, newer creation dates????? So this could be something outside of Retrospect?

 

For information I did an upgrade to 7.7 - to keep my original scripts. Worth trying un-installing 7.6 and starting afresh?

 

Would very much appreciate any input as it's the only remaining issue preventing Retrospect operating perfectly.

 

Steve.

Link to comment
Share on other sites

OK upgraded to 7.7, I still have the execution errors. Some of the duplicate files continue to have newer creation times. ... Not only that but I also tried copying the offending files to a separate folder manually and they had the same, changed, newer creation dates????? So this could be something outside of Retrospect?

Sure sounds suspicious. If I was a Windows hacker, I could tell you how to investigate, but I'm not. I would suggest, though, that you look at the metadata properties of these files (creation, modify dates, etc.) to see if anything looks odd. For example, sometimes the creation of a new file (as happens in a copy, whether by Retrospect or by a system copy) will sanitize the metadata to correct anomalies in the source. For example, it's shouldn't be possible to have a modify date that is earlier than the creation date. So perhaps there is some sanity adjustment happening in the metadata when the replicated file is created, independent of Retrospect.

 

Here's another thought: Is there something different about the underlying filesystems for the source and destination, or is there some odd history of the filesystem on which the original files sit? E.g., NTFS vs. some other format, etc.

 

For information I did an upgrade to 7.7 - to keep my original scripts. Worth trying un-installing 7.6 and starting afresh?

Sorry, I can't help you there. But you might want to search these forums for posts in the last week or two following the 7.7 release. I seem to recall some comments by people who did the update and then went back and did the fresh start to clear up some issues.

 

As for the "execution errors", that sounds like a different issue. Exactly what errors are you seeing? Anything other than the different date/time error reported in your initial post?

 

Russ

Edited by Guest
sanity checking, filesystem types
Link to comment
Share on other sites

Russ,

 

All the creation dates within the duplicate (of the offending files) are newer than the originals. many, but not all, just by a few seconds. What I don't understand at all is that copying the duplicates back to the original folder and over writing what is there, then doing the duplicate process again produces the same issue.

 

All my drives are NTFS.

 

The only other execution errors that I have seen were permission errors when trying to copy data to/from my NAS drive. That I have sorted out, or at least I am not getting the errors at the moment.

 

What are the options? Store the files producing the errors somewhere else manually so that retrospect doesn't have to deal with them? Sort of defeats the object, complicates my file system and backing up if I were to modify them again etc.

 

Thanks.

Link to comment
Share on other sites

Well it looks as if the creation dates for all these photos are newer than the modified dates (which ties in with the date the photos were taken), hence why Retrospect is duplicating them again each time. Why Retrospect is only highlighting a small subset of these within the errors log (about 1 in 10) I do not know.

 

So does anyone know how I can re-set the creation dates on these photos etc? If I can do that it would solve the problem I think?

 

Steve.

Link to comment
Share on other sites

There may be some Windows utility that will sanitize the metadata. Sorry, I'm not enough of a Windows hacker to know the solution.

 

However, because you indicate that manually copying the files to a new destination fixes the dates, I would guess that one way would be to copy the set of files to a scratch place, then copy them back, replacing the originals.

 

Russ

Link to comment
Share on other sites

Hi Russ,

 

Thanks for taking the time to provide input to this. Appreciated.

 

The dates seem to revert once I copy them back from the duplicate folder, even to different folder. It does it whether Retrospect is copying or I am copying manually? Must be a windows setting? For the time being I have set Retrospect to "Duplicate missing files only" so that it ignores the difference in creation dates between the 2 folders (source and duplicate). Stops the error messages and the prolonged duplication process. Not an issue with photos as I won't be modifying the originals without saving as a new file so only new files will ever need copying. However I would love to get this issue sorted out so if anyone knows how to correct the creation dates on these files (photos) please let me know!

Link to comment
Share on other sites

This only happens when backing up to NAS (in my case iomega ix-200)

backing up from local disk to local disk works fine.

For some strange reason, several files have a 2-3 seconds difference in create date after backup. This cause the vefification error. That in itself is not a big problem BUT it causes these files to be continually backed up every time I run express. Since these files consitute nearly 50GB it means every backup takes a whole day - which defeats the whole point of having incremental backups.

If it does not get resolved soon, or a workaround I will have no choice but to return my NAS drive (since it came as a package with retrospect) before the warranty period expires because right now it's totally useless to me.

 

Link to comment
Share on other sites

This frustrating but I can only assume others are not seeing the issue?

 

Is there a setting within Retrospect that allows you to turn off the creation/date time matching whilst leaving the modifying date/time matching criteria etc in force?

 

Why i have creation dates that are after the modified dates on so many picture/video files I do not know - if only I could correct that I'd correct the source of the problem.

Link to comment
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.

Guest
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.

Loading...
×
×
  • Create New...