View Full Version : nukex6.2 64bit writing tga sequences crashes
01-24-2011, 11:45 AM
hit render for any sequence recently and nuke will crash with this message:
Write1: Can't rename .tmp to final, Permission denied
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:/Program Files/Nuke6.2v1/plugins\nukescripts\renderpanel.py", line 8, in render_panel
return nukescripts.showRenderDialog(_list, exceptOnError)
File "C:/Program Files/Nuke6.2v1/plugins\nukescripts\renderdialog.py", line 623, in showRenderDialog
File "C:/Program Files/Nuke6.2v1/plugins\nukescripts\renderdialog.py", line 231, in run
nuke.executeMultiple(self._nodeSelection, frame_ranges, views, continueOnError = self._continueOnError.value())
RuntimeError: Write1: Can't rename .tmp to final, Permission denied
this seems to be happening more and more frequently. the only fix i've found so far is to create a new write node with new location and file name.
it leaves a temp file where the sequence stops rendering, but deleting this still causes the crash in the same place. Anyone else getting this? I 'mm wondering wether its windows7 and not nuke?
01-24-2011, 04:35 PM
Well It Seems That It Is A Bug For Version 6.2, That Did Not Exist In 6.1.
So There's The Solution, Use An Earlier Verison.
01-25-2011, 05:53 PM
Sadly it existed in all versions of Nuke. You've only just noticed it now.
When rendering, Nuke writes temp files and then changes them to the image file upon completion. Sometimes the operating system stuffs up and won't let you change the temp to an image. Delete all the temps and hit re-render.
01-26-2011, 02:21 PM
Yes, thanks for that, i still recon win7 is having a hand in it.
strangely enough, even deleting the tmp file- it still crashes.
what is even stranger...i can read/write quicktimes....in nukeX 64bit.
i thought quicktimes were a nono on 64bit windows?
01-29-2011, 11:14 PM
Do you have things like search indexing and volume shadow copy disabled?
Also, as of 6.2v1, it's possible to read and write Quicktimes on 64 bit Windows.
02-13-2011, 08:10 PM
i just had the same problem and i solved it by turning off my windows 7 user account controls.
02-28-2011, 12:09 PM
hmmm do you mean the slider control you can set to never notify? it is already, but the problem still occurs.
06-01-2011, 02:53 AM
Hey did you fixed this??
I have a huge project here, and I started getting this *****ng error over and over... Itīfreaking me out.
Iīve tryied it all, deleting caches, deleting the .tmp file, executin nuke as admin, the UAC is off....
yesterday the error appeared, and deleting the cache and the tmp worked, now It doesnīt.
I need to do the final render for tomorrow, donīt know what else to do :argh:
06-02-2011, 10:22 AM
Nope, it still occurs from time to time.
the best way i found was to tick the "render in background" box and do it that way, seems to thrown significantly less errors.
also, rendering to exrs instead seems to work.
06-02-2011, 06:53 PM
Did you use name####.tga in the write node?
Do you run any other memory consuming app at the same time?
06-08-2011, 04:54 PM
I was having the exact same problem as joecoke69, trying to render a JPG sequence. It started to happen TODAY, yesterday was all fine.
I use the render in background, as he suggested, and also use the kyrgr suggestion of the NAME_####.jpg (i was using %04d) and now is rendering, a little bit slower, but rendering.
Donīt know what fixes the problem, though.
Is there a bugfix or something?
06-09-2011, 03:52 AM
You guys should really report this to firstname.lastname@example.org. They can't fix it if they don't know about it.
04-10-2012, 04:08 PM
Hey there guys...
i thought i'd chime in and ressurect this thread, as i have stumbled upon this on a rather large project, had driven me close to insane, and looking up a solution online yielded absolutely no useful information, apart from a couple of hacks that did no work.
Enabling administrator permissions, logging in as admin, changing disk permissions etc, even reformatting and reinstalling the system did not fix this. It is a windows specific nuke bug (does not happen on linux or osx).
The only thing i have discovered that fixes this problem, is to close down nuke, remove its temporary folder completely (appdata/local/temp/nuke - on windows7), then restart the app.
Using clean buffers and disk cache does not fix it.
Afterwards all behaves as expected. Mind you, once the temp folder fills up, the problem might come up again, but at least this allows you to render sequences without the annoying "can't rename" crap popping up.
As a sidenote, what i did, was to create a simple batch file that would first remove the folder and all it's subfolders, and then start nuke. That way, everytime i run the app, i get a clean run. Downside is, if i have large trees, they need to recache, but at least now they render....
07-31-2012, 08:39 PM
I will spread this temp folder delete method - it is the only answer I've found that actually works.
08-23-2012, 05:47 PM
I had problem with same issue time to time and I resolve it as save sequence in another hdd dffrent folder and carry it my proper folder after finish the render (Like D:/render/blabla.###.tga)
04-19-2013, 08:21 PM
In spite this being a rather old thread, I thought I'd give my input since this problem just happened to me today.
I got this "Can't rename .tmp to final, Permission denied" today while trying to use the flipbook render and the write node.
My proyect included hd tifs both in sequence and stills and a quicktime mov, working in Windows 7, Nuke 6.3v4
This I tried:
- Delete Nuke cache - no solution
- Close and open Nuke - no solution
- Turn off and on the computer - no solution
- Move the whole proyect to a local drive (against keep working on the server) - no solution
- Open the proyect in another computer - no solution
- Delete the "appdata/local/temp/nuke" files - no solution
- Then a colleague suggested to convert the mov to a tif sequence - THERE IT IS!!
So, just wanted to post this in case someone else has a similar situation, I hope this helps!
04-22-2013, 11:43 AM
if your QT mov file was also on the network/server then probaly somebody else had this file open so windows wasnt able to overwrite this file.
07-05-2013, 05:50 PM
Hi everyone, i had the same issue because two machines where rendering in the network with the same name for the clip to export. I simpli change the name of the render in one of the machines and the error dissappear. Hope this help
In my case, I was having my viewer connected to the writer node, so it was causing some kind of loop operation. It seems you can't view your writer output since it has to replace it with the render O_o
So the solution is quite obvious..., just pipe the viewer to the last node before the writer one and everything works again.
vBulletin v3.0.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.