redk9258, I indeed thank you for helping, but in a friendly and humerous manner I reply, the comment about changing the oil with the engine running really doesn't help at all. I can change the brake lights, even transmission fluid on a manual, and many other things while the engine is running on my car. This relates back to wondering if the service tracks the filename changes.
Anyway, I might have the problem resolved. First, deleting and recreating the partition didn't help. I then stopped the service, copied all the files in C:\Documents and Settings\All Users\Application Data\Symantec\Norton Ghost elsewhere as backup, deleted ALL the files under History and Schedule. Started the service. Ran Ghost. Cancelled the automatic first-time backup setup. Created a recovery point for my partition in question, and it let me do a new recovery point set. I then exited Ghost and stopped the service again. I then copied most of the saved files back to where they came from. Started the service again. Ran Ghost again. I can now see from within Ghost all my old plus one new job. I can also see the history of when those jobs backed up, and when all will occur in the future.
One exception. When copying the history back, there was one filename collision, for which I did NOT overwrite. This means that when I ran Ghost having an empty History folder, it created a new filename. I believe this file related to my new job, and I believe I recall looking inside and seeing my volume name. Meanwhile, the backup version with the same name contained a volume name corresponding to my boot volume (which is on the same physical disk as my new volume in question).
One of two things has happened. Perhaps this .pqh filename collision points out the fact that I had not successfully removed the offensive .pqh file before. That is, while I had identified two other .pqh files that might be causing Ghost to remember my volume and refuse to allow me to create a new recover point set job, this may have been the actual one causing the trouble. Due to the content not appearing as I expected, I didn't find it and didn't nuke it. I am NOT going to go back and reproduce the situation, to confirm this, because I need to move on to my actual work needs.
Alternatively, this filename collision is a red herring. This would mean there's still something magical (technology sufficiently advanced being indestinguishable from magic and all that) about stopping the service first, rather than merely rebooting after running the engine with no oil for a moment. This would also mean that the .pqh filename creation is neither a unique process nor specifically tied into the volume properties -- which I doubt.
Therefore, I really suspect that the first situation is the case, and I didn't really need to stop the service, but just nuke the correct .pqh file. This doesn't mean that stopping the service wasn't a good idea.
So, hopefully there backups will actually OCCUR, and I don't have some other magical setting messed up. I'll find out soon enough.
In the mean time, I sincerely thank you, redk9258, for your help. You led me to a solution.
