This happens to me all the time. When I try to save a file, Renoise writes it all out and then pops up a message saying that the file could not be saved, and that I should check to make sure I have enough disk space. I most certainly do have enough disk space, and, oddly, the file is saved just fine.
This also happens occasionally when I try to copy/paste samples. It’ll say that it couldn’t write an intermediate file and that undoing the paste will not work. Occasionally, it will also say that it can’t find the temporary paste buffer, and no paste will happen at all. I have to restart Renoise to get it working again.
Does this only happen when overwriting existing files?
We are already working on a workaround for this. Unfortunately this seems to happen on some systems one, mainly on Linux, but also on Windows and we could not reliably replicate the problem so far.
(Dunno if it is OT or(non)related, but I’ve also have had this problem on my buggy system trying to save files. Renoise doesn’t give a bug notice saying I need to free up harddisk space however, but says that there isn’t enough Ram free to save, it still saved the song though.
I think there was some kind of memory leak as there was a vst crash earlier, ctrl+alt+deleting to the task window revealed Renoise was almost taking up 2 gigs of ram, while the particular song shouldn’t use that much. Maybe you can check the task manager and see if there is similar odd things going on with Renoise ram consumption?)
@TakTik: Yes it is very difficult to get Renoise to produce the ‘saved but could not move’ error dialog
unfortunately I notice that the error is more likely to happen when the hard drive pages in/out data
or there is a certain type of hard drive activity that the operating system performs. This could happen
within 3 minutes of loading renoise or you could be trying for over 5 hours and not experience the problem!
I still say that it is related (from a Linux point of view) to the OS System call that performs the final ‘mv’ of the song e.g.
if mv -f ‘/home/RenoiseSongs/testsong.xrns.tmp’ ‘/home/RenoiseSongs/testsong.xrns’; then exit 1; fi
When you execute the above with the system call, it could get interrupted
(by some complex HD or memory OS activity maybe?) in which case it will return -1 if it fails
(crude c source code follows to help illustrate ) e.g.
#include <errno.h><br>
#include <stdlib.h><br>
<br>
int SaveRenoiseSong()<br>
{<br>
int result;<br>
result = system("if mv -f '/home/RenoiseSongs/testsong.xrns.tmp' '/home/RenoiseSongs/testsong.xrns'; then exit 1; fi");<br>
if(result == -1)<br>
{<br>
//Oh No! The OS returned a -1 system fork failure!<br>
//Pick up the error number and save it in errsave<br>
//(just in case OutputRenoiseLog overwrites the value)<br>
<br>
int errsave = errno;<br>
OutputRenoiseLog("Mv -1 save error number: %d",errsave);<br>
<br>
//Do some magic here depending on the errno (try the operation again? Not sure..)<br>
<br>
return FAILURE;<br>
}<br>
<br>
if(WIFEXITED(result))<br>
{<br>
if(WEXITSTATUS(result) == 0)<br>
{<br>
OutputRenoiseLog("Executed move save with no errors <img src="https://files.renoise.com/forum/emoticons/default/smile.gif" class="bbc_emoticon" alt=":)">");<br>
return OKAY;<br>
} <br>
else<br>
{<br>
OutputRenoiseLog("Failed to move file! With exit status: %d",WEXITSTATUS(result));<br>
return FAILURE;<br>
}<br>
}<br>
}<br>```
<br>
<br>
At least that way when the system call returns -1 or anything unusual, the error number in <br>
errsave can be examined from the log. The error number could then be cross<br>
referenced in the header /usr/include/asm-generic/errno.h etc.. to help isolate why.<br>
<br>
Just a thought however. In a nutshell I believe that the system call function is returning -1 in certain cases.<br>
<br>
Good tracker program Mr TakTik, hope you get the little bug ironed out <img src="https://files.renoise.com/forum/emoticons/default/smile.gif" class="bbc_emoticon" alt=":)"></stdlib.h></errno.h>
Thanks for the example and feedback. We do check the “system” result already, logging the error number may help to find out more. Will do so.
For now we are simply avoiding a “system(mv)” fork, and use “rename” instead. Both files will be on the same filesystem, so “rename” should work just fine in this case.
I notice that the error is more likely to happen when the hard drive pages in/out data
) e.g.