Copying a large amount of persistent refs causes an extra corrupted record to be generated

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using the attached file, select all records in  [03] temp_LODs.esp \ 
Worldspace \ 0000003C <Tamriel> \ 00000D74 \ Persistent
2. Copy as override into another ESP. In this specific case, into the USKP.
3. Try to save the file.

What is the expected output?
The file should save, with the updated records copied.

What do you see instead?
A corrupted record is generated instead, as per the attached image file. 
TES5Edit cannot save the file and cannot remove the corrupted record either.

What version of the product are you using? On what operating system?
Version 3.0.31 r1403

Please provide any additional information below.

Original issue reported on code.google.com by arthmoor on 21 Sep 2013 at 7:11

Attachments:

• temp_LODs.esp
• corruptedrecord.png

[GoogleCodeExporter]

The problem record is [REFR:000688B5], it is already in USKP but temporary. 
Setting it to persistent before copying avoids the problem (actually TES5Edit 
shows that in messaged tab) since persistence puts references in another cell, 
and doing it now while copying produces weird effect.
However copying with override doesn't overwrite existing records in another 
plugins I think, it simply does nothing. Afaik it always worked that way, so in 
your case you need to delete those records from USKP first.
Quite possible that persistent over temporary copying bug existed from the 
start even in original Elminster's versions.
I'll change owner to Hlp since he already messed with that code before (while 
modifying master additions probably, or maybe I'm wrong), and understands inner 
working of xEdit far better than me.

Original comment by zila...@gmail.com on 21 Sep 2013 at 8:20

[GoogleCodeExporter]

I figured that out after I went to start doing them one at a time, which worked.

Perhaps possible to just skip anything in an operation like this that already 
exists? This isn't the first time something like this has come up to be done. I 
guess up to now we've just been lucky.

Original comment by arthmoor on 21 Sep 2013 at 9:11

[GoogleCodeExporter]

Lets wait for Hlp first, maybe it is an easy fix.

Original comment by zila...@gmail.com on 22 Sep 2013 at 5:40

[GoogleCodeExporter]

Sorry, I got a cold last week and I am not very good at thinking right now :)

I'll look this up next week.

Original comment by HuguesLe...@gmail.com on 22 Sep 2013 at 9:21

[GoogleCodeExporter]

I just started looking at that, and, as far as I know, you are not supposed to 
copy as override over an existing FormID. Now, it should be detected and the 
file removed from possible targets.

Original comment by HuguesLe...@gmail.com on 23 Sep 2013 at 11:48

[GoogleCodeExporter]

Yes it won't even show "Copy as override" if record exists in destination 
plugin, but if a several records selected it doesn't check.
wbCopyElementToFile checks for it afaik, strange that it even tried to copy and 
produced that bug.

Original comment by zila...@gmail.com on 23 Sep 2013 at 11:54

[GoogleCodeExporter]

I can workaround this one by checking the FormID before trying to create the 
record, but the issue is far more generic:
  if an exception is raised inside a creator, refCounting code will apply to an undefined/incomplete record and will itself generate an exception that will be the one seen.

Original comment by HuguesLe...@gmail.com on 19 Jan 2014 at 4:47

[GoogleCodeExporter]

I'm not a fan of workarounds when underlying issue is known. Let it fail as it 
is for now until the reason is found.

Original comment by zila...@gmail.com on 19 Jan 2014 at 5:32

[GoogleCodeExporter]

The root of the problem is that the creator adds self to a container, but then 
the exception fails the creator which frees Self without removing it from the 
container.

I modified the TwbMainRecord creator to remove self from the container in case 
of exception later, but the same issue can arise from any creator inherited 
from TwbElement. We will have to check them all for possible exception.

see r1514

Original comment by HuguesLe...@gmail.com on 20 Jan 2014 at 11:46

• Changed state: Started

[GoogleCodeExporter]

Original comment by HuguesLe...@gmail.com on 3 Jun 2014 at 6:12

• Changed state: Fixed