My experience with GoBack shows that GoBack tool CAN BE the issue. Even disabling it did not help me. Complete uninstall - perform all actions I needed and reinstall GoBackup. This is the only scenario that works.
OS selector is a simple Boot Manager and it does not have advanced features to perform the actions you described. At least I have never seen them.
And the fact that directories were put to USB drive - this can be done by GoBackup as a backup as well.

Let me clarify.
At first, with GoBack enabled, nobody even recognized the partition.
Disabling GoBack un-mangled the partition information,
allowing everybody else (ERD, UBCD, windows) to see all the directories on the drive.
I need to get back to this point, because what happened next, with AOSS is the problem.

The infected IDE drive, with a full install of windows XP, with GoBack disabled,
was hooked via USB to the bench system with a brand new install of AOSS.
AOSS, as part of "managing" boot partitions, does indeed move files out of the three
folders I mentioned, and boot.ini into the Bootwiz tree to keep them
from being recognized as bootable by anybody else.  I didn't find this out till later.
I found the files and tried to move them back. it looked successful but wasn't.

I need to return to the point before AOSS changed it.

If I understand correctly, AOSS -WILL- return it to that point,
IFF I can put the files back where AOSS moved them to.

Ack...
Not requesting a close.  
Assumed I was still in a standard comment box.

Still clarifying.  The folders were moved from the root of the USB drive (F:)  to the same drive,
F:\Windows moved to F:\bootwiz\random#\Windows

My C drive is not a problem, Windows is still where it belongs.

This is not a Backup malfunction, no files moved across disk boundaries.
I will uninstall GoBack, once I undo the damage I did to AOSS's process.

But thanks for trying.

Will download and try AOSS to see what it does in fact. So the problem is external HDD, am I correct?

Yes, external disk, via USB.  
The disk was bootable at the start.
I discovered it was AOSS that moved the files from here:
https://www.experts-exchange.com/questions/21591619/Dual-Boot-XP-original-OS-doesn't-boot-and-system-Folders-are-empty-hal-dll-missing.html?sfQueryTermInfo=1+bootwiz+empti 

Can you take a screen shot of Windows Disk Management and post it here?
Also give me the version of this OS selector. I have found in my old baggage version 8.0 but that is data 2002!!!

v10, screenshots to come

The disk won't boot up it's own system, so the only way to get the diskmanager snapshot is to add as a USB drive on another system.
Since I don't want the bench system's AOSS to again modify the disk structure,
here's some snapshots as the disk appears on a system without AOSS.


pic001.jpg

DiskManager pic1
pic002.jpg

2) the detail from disk manager,
3) the root of the drive  ... looks normal
4) trying to open a folder inside of \Windows results in error.
pic003.jpg
pic002.jpg
pic004.jpg

Noxcho,
Thanks for the suggestion.  I've been avoiding making assumptions, since the product is known to (legitimately ) subvert standard windows mechanics as part of it's requirement to function, and my last assumption is what got me here.  I may have no other choice since I'm not hearing from anyone that knows what/why this happened.
I'm also waiting on word from the vendor's support forum, since I have to be out all day today, It'll be tonight before I can try your suggestion.

Thanks again.

Update:
Though the vendor is silent in their support forum, a fellow user of the product, "MudCrab", who has become the resident expert of the forum,  heroically stepped up and experimented until he duplicated the behavior.  Here's a summary:
-- clip
When OSS adds a Windows OS, it detects the version of Windows and automatically sets up the system folders. These would be C:\Windows, C:\Program Files, and C:\Documents and Settings for XP. For each of these, restoring the folders back to the original locations can be enabled or disabled. The default is disabled (they remain in their original locations). I have no idea why OSS would automatically enable this option for the Windows on the attached drive. (From an old post by Acronis Support on Wilders, it looks like OSS 9 did copy the files by default, but it's unclear whether it was the system folders or only the booting files -- which are tracked for changes.)

If you still have OSS on the bench computer and haven't changed anything, it may be possible to use it to disable the option for the OS on the attached drive. However, the same problem remains: you moved the files. In any case, this method would probably be more likely to succeed than on the original computer as long as OSS still sees it as it did before (same OS ID, etc.).  
...  
I ran a few tests.

Enabling folder protection moves the folders when you click OK on the Properties window (no reboot or booting into the OS is required).

Disabling folder protection moves the folders back when you click OK on the Properties window (no reboot or booting into the OS is required).

This seems like the simplest method to use if OSS will pick it back up as the same OS. Just disable folder protection for the three folders. Note that the contents of these folders MUST be back in the BOOTWIZ\#### sub-folders for this to stand a chance of working.

-- end clip

So, I have some hope. Here's my plan of attack...

1) restore the MBR from backup (MBRfix was last thing I did before seeking help, first to undo)
2) force ownership of the inaccessible files, hoping no other tech wizardry was performed
3) move the files back where I found them
4) see if I can figure out how to ask OSS on the bench system to undo his deeds
    (is there something other than uninstall that will accomplish the undo?)
5) chkdsk
6) try again to dupe the partition
7) replace the disk in the original system
8) boot
9) remove GoBack
10) reboot
11) On bench system uninstall OSS

Suggestions welcome, it will be afternoon before I get back to try this.

So it turns out that OSS did the backup of the OS files though you did not ask to do that, correct?
They do suggest creating boot CD to restore the system to the state before OSS manipulations. At least the old version I used did suggest that.
If that does not go then your steps look as last hope. This is before you reinstall the Windows.
The fact that you still have GoBack on machine worries me but seemingly it should not cause any complications.
If you manage to copy back all system files to original location and connect the drive as internal then we can try to make it bootable.

> So it turns out that OSS did the backup of the OS files though you did not ask to do that, correct?
Yes, it immediately happens when an option is chosen.  Which apparently it defaults to in this circumstance, since I didn't choose it.

They do suggest creating boot CD to restore the system to the state before OSS manipulations. At least the old version I used did suggest that.  
In this case, when I installed OSS, it was a bare-bones test partition, which I had already backed up and "hidden" the copy.  The manlement happened when I later added the USB mounted disk, so a backup boot CD wouldn't have helped.  These complications may be why the vendor ignores the support forum.
... out till afternoon now, then the final attempt.

That is not the news that their team answers long. Either the OSS is discontinued product or they have too much to do with other problems.
Go on with copying files via ownership taking.

Here's what I went through to solve the problem.  The numbered steps relate to the plan I listed above,
which was not far off.

1) restore the MBR from backup (MBRfix was last thing I did before seeking help, first to undo)
2) force ownership of the inaccessible files, hoping no other tech wizardry was performed
    did this on laptop, disk mounted on USB.  Turned out eventually that it didn't completely set the
    permissions, but enough to get the job done at this stage
3) move the files back where I found them
    The move took much longer than any span of time the bench machine ever spent,
    leading me to believe AOSS transplanted directory entries manually bypassing windows routines.
    (there's an example of the kind of wizardry I expected).
4) see if I can figure out how to ask OSS on the bench system to undo his deeds
    (is there something other than uninstall that will accomplish the undo?)
 
   OSS saw the partition as Windows, but said the boot partition was missing
   and offered no options.
   By groping around the menus I found the setting for "protect the files"
   but changing its setting did nothing about moving the files.
   so I moved them manually (after taking ownership on the bench machine)
   Ran the OSSelectorSetup in c:\program files\acronis and choose to uninstall it.  reboot
   The bootwiz folder is gone off subject disk drive
   In theory, we should be back where we started before OSS mangled it, though the
   "boot partition missing" from OSS isn't encouraging
5) chkdsk  
   As I'm about to run chkdisk via USB on Bench system I notice the disk is set for
   "compress drive to save disk space"  ... hadn't noticed that before.
    checked chkdsk options:  fix file system errors and find & recover bad sectors

6) try again to dupe the partition
   this time it worked
   
7) replace the disk in the original system
8) boot
   
    Boots up to black screen white cursor only, disk activity stops
    WooHoo ... Praises for no blue screen
    30 minutes later... no change,
    no response to ctl-alt-del, no response to inserting a CD that has autorun
   safe mode - bluescreens with complaints specific to add a disk or disk driver.

   Off to experts-exchange to solve this problem
   Bummer, 105 "solutions" first 5 all end up re-formatting
   try ERD, check event logs, disable a goback service, a norton service, & MDM,
   try reboot, no change.  reboot with logging enabled, still white arrow.
   reboot ERD, to see boot log at   "systemroot"\Ntbtlog.txt
   here's a surprise, smirk, 3 of the last 4 lines reference symantec,
   systemroot/system32/drivers/n360...  
   programfiles/commonfiles/symantec shared/...
   10 lines up another half-dozen references...
   ok ... lets try lobotomizing norton...
   go to open ProgramFiles and Windows folders, explorer hangs, regedit too
   reboot ERD (it's so fragile, and slow to boot)
   (later discovered that some files in Windows and Program Files folders still had bad permissions.)
   lsasetupdomain owned the stuff.  (leftover from old domain membership maybe)

   booted into UBCD4win, reset ownership and access, and did
   renames:
   systemroot/system32/drivers/n360...  to zzzn360
   programfiles/commonfiles/symantec shared/...   to zzz symantec

Now on boot we get as far as welcome screen ... progress
   even gets to user selection.
   click on the username, immediate "save settings (logging out)
    Permissions still?  Let's brute-force it.
   reboot into ERD, reset all permissions on all files on C: to full access
   results in lots of attempts to access a token that does not exist

   Reboot ...  Viola!  We're in!   shut down, make a copy of partition,
   Reboot ... remove norton ... moving toward sanity.
   Reboot... remove GoBack

I've not yet repaired the file permissions, but I expect Microsoft's KB 313222 will do well enough since it's now a solo home system.

WOW. My applauses for such a technique.
I like you wording: ok ... lets try lobotomizing norton... =))))))
And finally, if you plan ever to use several OS on single machine look this article: https://www.experts-exchange.com/articles/OS/Miscellaneous/Multiboot-system-configuration-from-scratch.html
And thanks for points.