class DirGuard
{
public:
char tmp[MAX_PATH];
DirGuard(std::string dir)
{
GetCurrentDirectory(sizeof(tmp),tmp);
SetCurrentDirectory(dir.c_str());
}
~DirGuard()
{
SetCurrentDirectory(tmp);
}
};
get set currentdirectory win32 base
Author
Hi
I have a problem using get set current directory in a multithreaded environment. My program is a plugin (dll) that is loaded from another application. The problem is that my set and get current directory calls messes up the opening of other files by the parent process. I use a directory guard on the stack to save and restore the current directory. I still have problems. Is the working directory global to the process maybe? That’s bad......
suggestions?
I had similar problems lately, so I concluded that all threads of 1 process are operating in the same directory. Can somebody confirm this ?
My solution was a single interface for opening files. So every file opened in any module goes through the same code and that code is "guarded" so that only one thread can request a file at one time. Also that is the only code which is changing directories.
Although, most of the time, the main program is feeding the modules with the files it has opened. Still it has to be thread safe.
Author
k thx. im going with the absolute path way. include the full path to the file in all calls to fopen.
thx
thx
Quote:Original post by Demus79
I had similar problems lately, so I concluded that all threads of 1 process are operating in the same directory. Can somebody confirm this ?
My solution was a single interface for opening files. So every file opened in any module goes through the same code and that code is "guarded" so that only one thread can request a file at one time. Also that is the only code which is changing directories.
Although, most of the time, the main program is feeding the modules with the files it has opened. Still it has to be thread safe.
Confirmation. The current directory is a process information. Moreover, I don't see any need to change it. Is open("foo.bar") better than open(basedir + "foo.bar")? I don't think so.
If you know where your files are lying, just use the absolute path. If you are tired to play with thiese damn path, use boost.path :)
Regards,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement