Logged In: YES 
user_id=6405

Marlon didn't have access to this bugtracker, and wrote: 
 
> The existence of the ".tmp" files means they're not being 
deleted  
> when transactions are rolled back, or worse they're not being  
> renamed when the transaction is committed. What backend 
are  
> you using? 
 
Were using MySQL. When I reported the bug, both roundup and 
MySQL were 
running on the same WinNT4 server. By now, we switched over 
to a Linux 
server for both roundup and MySQL (that is why I needed the 
export-import 
feature. On Linux I checked the 'db/files/msg' folder and also for 
newer 
files (created after import) the tmp extension exists. So it's not a 
windows 
thing. 
 
> If at all possible, could you determine from the timestamp on  
> the ".tmp" files when they were created and hence which 
version  
> of Roundup you were using then?  
 
Altough we used 0.7.6 for a while, we switched back to 0.7.5 for 
a few weeks 
back (due to some minor query problem we encountered). 
Unfortunatly, I can't 
tell if both releases created the msg*.tmp files, but I'm 100% 
sure that 
0.7.5 does. The most resent msg*.tmp has a timestamp of 
'2004-10-06 11:34'. 
I looked up the message using the web-interface. The time 
stamp there is 
'2004-10-06.11:34:37', so we could say they are the same. But 
what I did see 
(when opening the message) it isn't linked to any issue. Also are 
all other 
msg*.tmp messages not linked to any issue, while all msg* (no 
tmp extension) 
messages are linked. I asked the author of the latest newest 
msg*.tmp 
message and he told me that the first submission failed due to 
wrongly 
filled in data (rejected by auditor). So I tried to do something 
with an 
issue knowing that the auditor would reject the issue update. 
The result was 
a new msg*.tmp file that remained there. So it looks like they are 
the 
result of an auditor reject. 
Hope this helps!