When I try to export our database, the export 
terminates with the next error:

Traceback (most recent call last):
  File "D:\Python23\Lib\site-
packages\roundup\admin.py", line 1273, in
run_command
    ret = function(args[1:])
  File "D:\Python23\Lib\site-
packages\roundup\admin.py", line 1043, in
do_export
    cl.export_files(dir, nodeid)
  File "D:\Python23\Lib\site-
packages\roundup\hyperdb.py", line 785, in
export_files
    shutil.copyfile(source, dest)
  File "D:\Python23\Lib\shutil.py", line 37, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory:
'D:\\RoundUp\\eccncr\\db\\files\\msg\\0\\msg2'

When I open the above folder, it does not have the 
file 'msg2', but it does have 'msg2.tmp'. 
When I use the web interface, 'msg2?@template=item' 
will show the content of 'msg2.tmp'.
If I rename 'msg2.tmp' to 'msg2', then still the web 
interface can it show the content. In other words, the 
code handling the web interface ignores the extension, 
but the command line export feature does not.

I tried this with roundup 0.7.5 and 0.7.6. Both releases 
have this problem.

FYI, the mentioned folder does contain a lot 
of 'msg?.tmp' files. Is this normal?

Regards,
Marlon

PS: I use the next command to export: roundup-admin 
export 'd:\roundup\export'

Logged In: YES 
user_id=6405

Sorry it's taken so long to follow this up. 
 
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? 
 
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? 

Logged In: YES 
user_id=1083360

I encountered the same problem here. My guess was, that
these uncommited .tmp-files come from experimenting with
detectors that raise Exceptions.

Probably the export should use the .tmp file if no commited
file is found, just as FileStorage.getfile() does.

stefan.

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! 
 

Logged In: YES 
user_id=6405

The .tmp files simply shouldn't *be* there. I've tried to reproduce 
a situation where they're left hanging, but can't. 
 
. new demo mysql tracker 
. add new issue with message 
. edit messagesummary detector to always raise Reject 
. add new issue with message - rejected 
 
In both cases, the .tmp file was dealt with appropriately (ie. 
either renamed or deleted). 
 
I'm not going to modify the code to use the .tmp files, as it'll 
mask errors. 
 
Closing the issue, noting that the work-around is to rename the 
files. I'll be happy to provide a script to do so if anyone runs into 
this problem again.