Our system has an annoying bug with the COPYTABLE command. Here is how it works.

Suppose you have two volumes, vol1 and vol2, with corresponding volume labels, lbl1 and lbl2. Further, suppose there is a file on vol1 named file1 (my creative juices are really flowing here), which is indexed, and thus has a corresponding index file !file1. Now, you wish to use COPYTABLE to copy it to vol2. Well, Arev, in its infinite wisdom, having learned from wailings from users of previous versions that it should be able to handle indexes seemlessly instead of forcing the user to remove and then reapply the indexes, does its best (?) to manage the indexes. However, it fails miserably. The result of the copy is that

file1 has been copied to file2 on vol2

dict.file1 has been copied to dict.file2 on vol2

!file1 has been copied to !file2 on vol2

lbl2 has been applied to ! and !file1 records of !file1 on vol1

lbl1 has been applied to ! and !file2 records of !file2 on vol2

This, of course, makes both file1 and file2 unupdateable, since the system reports that the !file1 or !file2 file is unavailable.

Has anyone encountered this problem? If so, what was the root cause and how did you resolve the problem? Some potentially relevant facts:

HR-1 5.5 (Arev 3.02 reported)

The file in question also has two MFSs, one of which I wrote.

I'm open to the possibility that it is a problem with an MFS. If so, what should I look for in the MFS? Is there a flow chart for COPYTABLE available that will assist me with debugging the MFS?

Did not quite understand all the table talk. (Your creativity is a bit

confusing) but it sounds to me like you have the following:

You are trying to copy a file from one volume to another volume

with the exact same file name?

If this is the case the computer will be confused as to what goes

where thus the index mixup.

Copy table to temporary file with different name then unattach

the first file.

Then copy the temporary file to newfile.

Note Relational Indexes will not work with FileCopy and Symbolic

Indexes probably will need to be rebuilt.

Thanks for the info. I'll test out your scenario on our test server. No relational indexes, so we're OK there.

Victor,

After copyying the table, delete the ! item in the !table, reattach the file on the volume you copied to, then do a LIST 1 {tableID} (N

and it should straighten itself out.

Larry,

I don't have a problem correcting the situation. My issue is why is the problem happening in the first place. Each time this happens (every few months I think) we catch hell from the users. If you think about it, copying FROM a system shouldn't screw up what you're copying from, but that's exactly what's happening here. I suppose we could disable the copytable command or something. Otherwise we have to live with random errors that happen when someone forgets about this bug and does a copy.

View this thread on the forum...