none
Brief accidental folder rename could bollox everything: is this right? RRS feed

  • Question

  • It looks like if you're not careful, you could pay a very high price for one small accident.  The preview feature might have saved me from a small disaster, as many of my files are irreplaceable and I can't afford mistakes.  Here's what happened.

    The main folder I back up to on my external hard drive got accidentally renamed at some point, so when I was about to sync and Synctoy said it didn't recognize the new target folder name, I renamed it exactly what it was originally and tried to run my pairs. ST then popped up something about the relations being recreated as new, so lacking alternatives, I proceeded, but checked out the preview first.  There was a lot of app data kinds of stuff to dig through, but things started to look fishy.

    After studying the preview for a bit, it suggests a lot of new content on the C drive that should get backed up/copied (to subfolders within the main folder on the external drive) was instead scheduled for deletion.   This seemed strange, since you would assume that being of newer file stamp, it would copy to the backup normally instead of getting wiped out by the older backup version that lacked it. 

    I'm assuming that Synctoy is saying, even though there were things added in the week or two since the last backup, since you renamed the target folder on the external drive, that's a newer change, it chronologically outranks all that not-quite-as-recent-as-seconds-ago stuff you added in the last week on the C drive, therefore I'm going to wipe out all the C drive updates, based on the older outdated version on the external backup drive.

    I know it's tough to foresee and plan for everything, but I would have thought ST might have been able to recognize this and prevent the problem.  Thank goodness I'm not a complete noob or this could have been serious. 

      1.  Should ST normally be able to recognize this situation and not time-travel everything into reverse?

      2.  Is my best option to wipe my external drive, recreate all my folder pair tasks from scratch, and run a new backup? 

    It seems like a high price to pay for something as seemingly innocuous as accidentally renaming a main folder on the external drive, but right now I'm after solutions.  At least I managed to save the few changes that were incoming from the external drive first.  I'm glad at least I'm discovering this too on a personal backup, hard as that would be to deal with, instead of small business data.

    Monday, June 21, 2010 7:39 AM

Answers

  • Edit to revise. 

    For about half an hour I thought this had an explanation in a substitution of a human-error substitution old external drive for a new, but now looks like that wasn't the case. 

    It did however look like the folders being deleted were inexplicably again (file timestamps looked identical) being deleted and replaced on the C drive using the corresponding backed up files on the external drive. 

    I'm forced to write this one off as one of the mysteries of the heuristics and assume the person on the other thread seeing more files than the new ones being previewed for update might have something other than a version issue.  Anyway, I'm going to close this thread as answered in deference to others, as it appears the items to be deleted off C were at least then recreated from the external drive, and I'd be pressed to even speculate why.

     

    Monday, June 28, 2010 7:39 AM

All replies

  • Not seeing a reply, so let me try to simplify this. 

    1.  I run a sync between a desktop and a folder on an external drive.  (This is a bidirectional sync instead of just echoing, because I also sometimes import files via the external drive that I create on an separate xp machine, since they can not be created on vista.)

    2.  Multiple sources on the desktop sync with corresponding subfolders inside the one backup folder on the external drive:  docs sync to docs subfolder, photos to photos, music to music, etc.  

    3.  I created new data on the desktop and expected it to copy over to the external drive. 

    4.  However, after that new data was created, the single/container/large backup folder on the external drive got accidentally renamed, then restored back to its original name. 

    When I ran the preview, instead of backing/copying new files from the desktop to the external drive, ST said it was going to instead DELETE all the new stuff on the desktop  to match/recreate the OLD configuration on the external drive instead.  This is the REVERSE of what you would normally expect a backup to do.  I can only assume ST saw the more recent timestamp at the higher level (because of the folder name change) and said, This is newer and higher, therefore it overrides any backups that need to be made down at the subfolder level (?).

         -- Is that how ST normally works?   

         --  I assume ST does not understand what really happened, and therefore I should delete/recreate the entire backup folder from scratch (about 200G) so that I don't lose my new data, right? 

    Thanks for any answers.

     

     

     

     

     

    Saturday, June 26, 2010 6:41 PM
  • Edit to revise. 

    For about half an hour I thought this had an explanation in a substitution of a human-error substitution old external drive for a new, but now looks like that wasn't the case. 

    It did however look like the folders being deleted were inexplicably again (file timestamps looked identical) being deleted and replaced on the C drive using the corresponding backed up files on the external drive. 

    I'm forced to write this one off as one of the mysteries of the heuristics and assume the person on the other thread seeing more files than the new ones being previewed for update might have something other than a version issue.  Anyway, I'm going to close this thread as answered in deference to others, as it appears the items to be deleted off C were at least then recreated from the external drive, and I'd be pressed to even speculate why.

     

    Monday, June 28, 2010 7:39 AM