Subject: [Boost-bugs] [Boost C++ Libraries] #9911: [Interprocess] get_tmp_base_dir(...) failure
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-04-15 17:22:33
#9911: [Interprocess] get_tmp_base_dir(...) failure
------------------------------+--------------------------
Reporter: Aaron_Wright@⦠| Owner: igaztanaga
Type: Bugs | Status: new
Milestone: To Be Determined | Component: interprocess
Version: Boost 1.55.0 | Severity: Problem
Keywords: |
------------------------------+--------------------------
In Boost 1.55 get_tmp_base_dir(...) is defined as such:
{{{
inline void get_tmp_base_dir(std::string &tmp_name)
{
#if defined (BOOST_INTERPROCESS_WINDOWS)
winapi::get_shared_documents_folder(tmp_name);
if(tmp_name.empty() || !winapi::is_directory(tmp_name.c_str())){
tmp_name = get_temporary_path();
}
#else
tmp_name = get_temporary_path();
#endif
if(tmp_name.empty()){
error_info err = system_error_code();
throw interprocess_exception(err);
}
//Remove final null.
tmp_name += "/boost_interprocess";
}
}}}
This makes an assumption in Windows that, if the "shared documents folder"
is not usable, the temp folder should be used instead. I believe this is a
bad assumption, and leads to silent run-time failures.
Every user in Windows is going to have a different temp folder. Thus,
processes running under different users will not agree on the same base
folder for boost_interprocess. This obviously defeats the purpose of
shared memory.
I believe a failure to secure a shared location in Windows for
boost_interprocess should result in an exception, not a fall back to the
non-shared temp folder.
PS - It would be beneficial if the location of the boost_interprocess
folder could be specified. Instead of relying on registry entries,
environment variables, or Windows API voodoo, I can tell the library
exactly what folder to use, and save everyone some work.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/9911> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:16 UTC