Uninstall Failures

[xarzu]

Have you ever installed a program and then when you uninstall, it keeps the files behind. Or does not do the uninstallation at all? What causes this and what can be done to make sure your computer is clean of the files?

[Paul Komski]

It happens fairly regularly and can happen either because whoever wrote the program wrote it badly or because you (or a reg cleaner etc) has deleted settings needed by the uninstall program. It can sometimes be corrected by reinstalling and uninstalling - but not always. Some use reg cleaners to clear up traces - though I personally find such cleaners can do more harm than good. System restore is another imprecise tool and the only way I know of to go back to a specific point in time is to have image files of your system made at appropriate moments for yourself.

[Sylvander]

An alternative to restoring an image backup [of the contents of the Windows partition] made immediately before the installation of the new software is...

Use something like [the latest paid version of] "SyncBack" to synchronise or backup [the contents of the Windows partition from the "source" to the "destination"] immediately before the installation, then afterward when you want to restore the way things were....
Synchronise or restore from the "destination" copy back to the "source".

The "destination" [backup] copy could be held almost anywhere you like.
e.g. In a folder on another partition, on the same internal HDD, or an external USB HDD, or a "Flash Drive" [if large enough].

Synchronising takes about 5 min instead of say 30 min for an image.

Images tend to be a snapshot of [the way software was at] a past point in time; might be 5 min ago or a year ago, whereas....

A synchronisation tends to be the very latest arrangement when last made; probably within the last 24 hours.
The "differences" [they are all listed] between the "source" copy [the Windows partition. probably C:], and the "destination" copy would show you all the file changes that had been made due to the installation.

The FREE copy of SyncBack does almost all the files, but not those in use [by Windows and Programs].

[Paul Komski]

I would never use or advocate such synchronisation to restore a system let alone put the registry back the way it was. Synchronisation is however a great way of keeping two sets of user data updated on two separate PCs.

BTW - it takes me about 3 minutes to image my 50%-full 10gig system patition whether using ImageForWindows or ImageForDOS or PQ's DriveImage2000.

[Sylvander]

"I would never use or advocate such synchronisation to restore a system let alone put the registry back the way it was"
Why not? :confused:
I believe the latest version of SyncBack is specifically designed and manufactured to be capable of doing this.

"it takes me about 3 minutes to image my 50%-full 10gig system patition whether using ImageForWindows or ImageForDOS or PQ's DriveImage2000"
WOW!

[Paul Komski]

I believe the latest version of SyncBack is specifically designed and manufactured to be capable of doing this.

Have you tried copying and pasting the file:-
%UserProfile%\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat

Well, maybe the shareware version SyncbackSE can lock it in order to copy it under WinXP - I will just have to try.

Results:
Syncback wont copy them whereas SyncbackSE v.4.1.3 does - so some humble pie from me there.

However there is still a real problem with making backups in this way and as with ImageForWindows or any other backup program that works from within Windows it cant restore your system till you get back into windows (or sometimes from a BartPE live CD if it has the correct plug-in; eg for DriveImageXML). ImageForDOS will at least restore Image files made by ImageForWindows but I don't know how you would get on with a non-booting system having used SyncbackSE without reinstalling an appropriate operating system first. I'm also not 100% sure if WindowsXP can always successfully lock the files in use (in association with appropriate software) but I believe that the PhyLock accessory for ImageForWindows is not always 100% successful.

Maybe I'm becoming out of touch but I remain a believer in backing-up and restoring systems from outside Windows. I began this philosophy with PowerQuest's Drive Image and Norton Ghost and have no good reason, yet, to change my outlook.

[Sylvander]

"Syncback wont copy them whereas SyncbackSE v.4.1.3 does"
That's what I thought, but I could so easily have been wrong.

"so some humble pie from me there"
None needed or expected; I wish I had your 99.99% record of getting things right.

"it cant restore your system till you get back into windows"
Quite so; I realised only after posting that I'd forgotten to mention that fact.
In practice I personally use it to SUPPLEMENT image backups, although for data files I think I might be prepared to stop using images, or put it in 1st place with images 2nd.
I always have an image of C: available in case Windows won't load.
And anyway, my FREE version 3.2.10 cannot synchronise or backup all of the files on the Windows partition [I've tried]; there are about 20 files in use that it cannot lock and I exclude those from synchronisation.
So far I synchronise C: mainly out of interest; not yet used it to restore files on C:. :)

"I remain a believer in backing-up and restoring systems from outside Windows"
Same here [for C: anyway], but I wouldn't mind giving the latest SyncBack a try for restoring C:. :)

[Paul Komski]

I remain a believer in backing-up and restoring systems from outside Windows
So apparently do the authors of the Radified Guide re Ghost

http://ghost.radified.com/norton_ghost_90.htm

[Sylvander]

Any idea how the latest version of SyncBack manages to copy [Windows & Program] files that are in use?

A LITTLE STORY
1. Various helpful people have sent me TIF image files of birth/marriage/death/census records that apply to individuals on my family tree.

2. Noticed that I'd marked some as "done", yet none of the info was included in the appropriate branches. :( :confused:
The files and the tree database are on my D: partition and SHOULD normally be safe and up-to-date, but at some point I probably restored an older copy/image of D: that matched an image of C: I needed to restore to fix a Windows/Programs problem.

3. This possibility REALLY WORRIES ME, because I can spend HOURS of hard slog entering data and their sources, and there's no way I would want to lose all of that and need to do it all again. :(

4. So I'm really glad [that sometime past] you suggested [among others] using "SyncBack", because this tends to naturally move only forward.
There is a 2nd copy of all the files on D: being held on the Flash Drive H: and I update them quite frequently [at least every day, and right after making significant changes].
I believe [provided I don't make any silly errors] that this will prevent a "jump back" and resulting loss of data.

5. Even if I restore an older image of D: the 2nd copy of all files is still up-to-date on H: and could be used to selectively restore the copies on D:
The only thing that concerns me is that [in such circumstances] I might get it wrong, mess it up, and lose data.

[Paul Komski]

What you describe is what I would consider the normal use and value of backing up using such software and such backups can be set to run as often as you like. This is, of course, the backing-up of data rather than a whole system.

With the paid version you can also make multiple incremental backups of the same file so that you can go back to earlier versions/editions of that file. If wanting to keep multiple versions of one file is important then consider using SecondCopy, which does this in a different way - a way that is analagous to the method used by PowerQuest's DataKeeper which used to bundle with PartitionMagic and was my own favorite until it became deactivated by WinXP's SP2. DK is still a great utility under Win2K however.

I've said it loads and no apologies for repetition but important data should only be stored in a safe place on removable media. CDR is particularly good since it wont be overwritten.

Any idea how the latest version of SyncBack manages to copy [Windows & Program] files that are in use?I thought this was a function of WinXP and later that allowed such temporary locking of such files to take place when requested by appropriate software.

[Paul Komski]

I thought this was a function of WinXPIt's actually a function that can be invoked with all the NT based OSes whereby the correct API call can temporarily disable any current handle (from another app or process) that is currently "locking" a file. I had assumed that the process was the reverse in that the program wanting to access a locked file had to lock it for itself - but that isn't the case as far as I can determine (but I am not good at programming API calls - other than a few familiar ones that I can call from VB).

It's thus worth saying that if the program you are using (to unlock rather than lock an existing handle) in such fashion (e.g. Phylock, Syncback, Unlocker) is running when any other third party software/drivers that also provide "snapshot or disk protection" are running then conflicts can still occur. According to the Phylock readme many of such utilities are ill behaved and will block requests intended for Phylock. I would think the same would be the case for Syncback and is the sort of reason that I and the Radified site prefer to stay outside of windows for backing-up system partitions.

The following quote taken from: http://ghost.radified.com/norton_ghost_90.htm
I'm sure Symantec has their reasons, but many (including myself) feel that imaging a live operating system (*from* a live operating system) introduces risks that are better avoided by using the original Ghost product (v2003), which works from DOS, when Windows is shut down, when it's unable to modify any of its files (such as the registry hive).

Admittedly, the risk is small. But if you have a problem with the restore, the results can be tragic. Personally, I prefer to avoid *any* unnecessary risk, which is why I still use Ghost v2003: the latest version of "true" Ghost (originally developed by Binary Research), which operates from DOS.

The same site also cautions against making encrypted image files - another thing with which I would concur.

It's easy enough to make backups but it is not always straightforward to restore them - and that fact is often forgotten about particularly when there is an "easy" way to make the original backup. That is the one of the main reasons for my plugging of BiNG and IforD.

[Sylvander]

Great info!

Thank you for taking the time and effort to explain and pass it on. :D