Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: MortenMacFly on August 24, 2006, 11:06:28 am

Title: "Unable to create temporary file" error
Post by: MortenMacFly on August 24, 2006, 11:06:28 am
Here are the steps to reproduce an issue I've just encountered. I know it's something evil I'm doing here, but the error message could be avoided anyway:
- create a new console project in a fresh directory
- open the main file
- open any explorer of your choice and delete the project folder completely
- switch back to C::B -> this will complain the file does no longer exits. click "no" to close the editor
- close the project
-> Error message: "Failed to create a temporary file name (error 267: der Verzeichnisname ist ungültig.)" (meaning: the path is not valid)
Should we take care of such things (the user removes a project's folder while the project is still open)?
With regards Morten.

Edit: Now that's weired: If I try debug into this, Im receive a sigsev in void ProjectFile::SetFileState(FileVisualState state) at the first line, because m_VisualState is not accessible...?! Why doesn't this happen in the release version?! Anyone who can reproduce this?

Edit2: (Revision 2891 on Windows.)
Title: Re: "Unable to create temporary file" error
Post by: thomas on August 24, 2006, 09:40:29 pm
Quote
Should we take care of such things (the user removes a project's folder while the project is still open)?
I think we should follow the Shit in = shit out rule. You cannot foresee every stupid thing that a user might possibly do. Where does it begin, where does it end? Do we need to check whether the user formats the hard drive, too? :)

If you save a source as "*.cpp" under Linux and then type rm *.cpp to delete this file, is this the shell's fault, rm's fault, or whose fault is it?  ;)
Should the programmers of vi or nano have forseen that you would do this?

Quote
Now that's weired: If I try debug into this, Im receive a sigsev [...]
Why doesn't this happen in the release version?!
Because there is no real segfault, the debugger only catches a signal that is sent (but otherwise harmless). No debugger, no error message.