Flaw in Drive Snapshot v1.38

As reliable as Drive Snapshot is, I have stumbed upon a flaw... As some of you know, I'm a Rollback Rx user and have successfully imaged (& restored) my entire C-partition (including all RB snapshots) by booting-up with UBCD4Win and running DS, creating a Maintenance Mode image of my system partition.

Today, after creating an image of my C-partition (C-MM.SNA), I proceeded to create an image of my D-partition. But after designating the D-partition to image I was distracted when it came time to rename the file in DS' destination file box (the name of my previous backup, C-MM.SNA, still appeared in that box), which dawned on me immediately after clicking 'Start Copy'! I admit the mistaken name was my fault, but I expected DS to alert me to the existance of a file with the very same name (which it had created just minutes before) ...however that was not what happened - it proceeded on its merry way to overwrite C-MM.SNA with the image of my D-partition!

 

It not so much a flaw. Just have to remember DS inserts the last saved image you made and as most users backup the same partition with one image and use the same filename it's more a benefit but in your case not. Ideally a list of the last 5 image filenames taken in a dropdown be better and leave the main box blank perhaps.

 

Sorry to disagree with you, but as much as I think of DS, I definitely see that as a flaw... Since my original post, I tried to intentionally make that same mistake with Acronis and Paragon - both of them alerted me to the potential overwrite before proceeding!

I would much prefer DS leaving the destination file box blank with (as you suggested) a drop-down menu of recently created files.

 

yes i agree on that bit it should alert that you have a existing filename. i was saying if it left it blank so you left to type in a filename you would choose a different filename as careful users that backup usually know the name of there images.

 

Hi appster, you don't think you might be being a bit harsh on DS by calling this a 'flaw' do you? Some might see it as a beneficial feature .

Look at it this way, the fact that it had your previous filename in the filename box is a pretty strong clue that this was the last filename it backed up. As the developer is not known for providing 'non-essentials' (like a DOS menu!) then he was probably paying the user a compliment by assuming that they knew what they were doing when they clicked the start button .

However, what you could do (and what the developer has thoughtfully provided) is to use $DISK in your filename instead of specifically calling it 'C'. So, use $DISK-mm as your filename and it will automatically become C-mm.sna or D-mm.sna as appropriate . Similarly, you could add $year-$month-$day if you wanted, or $weekday.

Graham

 

appster tried to recreate this so called flaw you got and when i immediately backed up D after C with the same filename it prompted same filename exists already do i want to overwrite, yes - no. but there's a tickbox below 'don't ask again' so it won't alert. so you must of ticked this box at a previous time i would say.

 

Hi Graham,
I really don't believe I'm being harsh calling it a flaw. Ever since making DS my disk-imaging program of choice, I have never looked back and I won't now. However, it is common procedure when attempting to replace a file with a file with the exact same name (and path) to request confirmation. Not only does Acronis and Paragon do that, even Windows itself does that.

Graham, I'm probably missing something here, but had I used $DISK-MM, how would that have prevented my problem?

 

Mark, that is very strange indeed. I was never asked to confirm the overwrite. Also, as I placed snapshot.exe inside the UBCD4Wiin iso before burning the CD, I don't see how any changes to DS' default configuration could have been made (as I alway execute snapshot.exe from the CD)!

 

It would have prevented it because it would have used the drive name as part of the filename so it would have saved it with the filename which you were intending to use in the first place .

I suspect that there is probably a registry setting for this and when you created your UBCD4WIN then it may have already been turned off which will have been carried over to your boot CD.

Graham

 

To be fair, the next time I bootup with UBCD4Win (to backup), I'll run snapshot.exe from another location and then intentionally try to make the same mistake.

If this has been a false-alarm on my part, I do apologize.

 

Don't worry, I think it may just be because of the transfer of the setting to the CD. Markymoo's right, I 've just tried this on a fresh system and it does pop up a confirmation overwrite box with a check box to not ask again.

If you check the box then it writes a new registry entry 'DontAskBeforeOverwrite' and gives it a value of '1'. Deleting this entry or setting it to zero would make the dialogue box appear again.

Actually, having looked at the registry entries for DS, he provides for the last 10 filenames and also the last 10 hash filenames to be selected from a drop-down .

Graham

 

yes correct i give you that but in this case as appster is running it from UBCD4Win the last 10 filenames will never be saved as the registry is loaded into a Ram Disk which is volatile and not like a permenant windows registry running from hard disk .

@appster
yep running from cd a few of the settings are lost. just remember you have to goto advanced and enable mm in your case.

 

@markymoo, that goes without saying ...in order to capture my RB environment and snapshots I always select Advanced and then tick the "MM' box.

When I return home today I'll boot up with UBCD4Win and then run snapshot.exe from its DS folder under C:\Program Files to see if doing that changes the 'action' of the destination box.

 

@appster

i'm just saying from cd it doesnt remember those settings otherwise it does.

if you make all your existing images READ ONLY then when you come to take an image it would not overwrite any images 'alert or no alert' so thats a sure way not overwrite your existing images .

 

markymoo, I'm wondering if making .sna files READ ONLY would interfere with creating differential backups?

 

I appreciate the cautionary note, but I only backup my system partition after booting up with UBCD4Win, so selecting Advanced > Maintenance Mode is second nature to me. But then again, "familiarity breeds contempt" (as I found out)!

 

no the original .sna files are not needed when making a differential. what is needed is the same drive choice you made the original image with and the .hsh file that was created at the same time you created the .sna file. all the info needed for the original backup is kept in the hash file along with crc info to make differential. the differential is created to a new filename . its kind of like Eaz-Fix snapshots. that take tiny snapshots of the Master File Table thats only 4096 bytes but can recreate the whole partition data structure from it. having said that it's a shame you can't recreate the original image from just the .hsh file that way you just have to keep your .hsh file and it not the end if you lose the images.

 

Now that would really be something!

 

That's possible. We received a similar complaint last summer, and silently introduced a) the warning before overwriting an existing image and b) the option to disable the warning. If your Snapshot.exe is older then ~Summer 2007 (I did't look it up), you never saw this warning.

 

Hi Tom - welcome to Wilders and thanks for acknowledging the 'flaw' as well as mentioning your silent fix for that issue. That would explain the different results among us DS users when entering a duplicate file name in the destination box! I will download your latest build when I return home.

 

appster

if you not using the newest 1.38 then i'm wondering why not? if you just seen that overwrite popup in the past you might of subconciously ticked it in the past and not remember and my guess is you been using a recent version that has that feature because if you bought it i'm surprised you wouldnt be using the latest update. if you been using the trial you had to been using it recently. What is the date at the top of the Snapshot window?

I dont know if prior to Summer 2007 was still version 1.38 or was 1.37 or older if so we can say there is not this flaw in 1.38. Anyway just use the new version then there is not this flaw.

 

As Tom stated, there was a 'blind' update to v1.38. The build of v1.38 I was using (and experienced the dup file name issue) had a date of Jun 22 2007, whereas the build of v1.38 I downloaded yesterday has a date of Feb 13 2008. Sure enough, the dup file name issue goes away with the current build!

 

I seem to have stumbled upon an issue with Vista sp1, once restore is done, DS alerts you that the drive may not be bootable, and you should run ... however actually booting the drive presents no issue. this wasn't the case before i updated to sp1.

Another small thing i noticed at the log window:

This should be GB. not MB.