[filesystem] create directory with wrong permissions

Hi there, when I am creating a directory with boost::filesystem::create_directory() the dir will be created, but the set permissions will not include 'executable' rights. Hance the application is not allowed to traverse into the dir it just created. System is Debian. With normal Unix functions all works well, so I think it must be another reason. Is there anything specific I have to do to ensure "drwx-r--r--" will be set? Greetings... Stephan

On 8/2/06, Stephan Menzel <smenzel@gmx-gmbh.de> wrote:
when I am creating a directory with boost::filesystem::create_directory() the dir will be created, but the set permissions will not include 'executable' rights. Hance the application is not allowed to traverse into the dir it just created.
What is your umask? What version of Boost are you using? The following code works properly here as a naive implementation of the "mkdir" command with the latest version of CVS version of Boost: --- #include <boost/filesystem/operations.hpp> using namespace boost::filesystem; int main (int argc, char** argv) { for (int i = 1; i < argc; ++i) create_directory (argv[i]); } --- % ./mkdir aaa % ls -FldG aaa drwxrwxr-x 2 cepstein 4.0K Aug 3 11:10 aaa/ % umask 002 -- Caleb Epstein

Am Donnerstag, 3. August 2006 17:13 schrieb Caleb Epstein:
What is your umask?
022
What version of Boost are you using?
Debian Sarge's included. It seems like 1.33.1
The following code works properly here as a naive implementation of the "mkdir" command with the latest version of CVS version of Boost:
I tried to reproduce it with a simple example myself but couldn't. Everything worked just fine. The code in question was inside a daemon, so I think it must be our fault somehow. Sorry for the inconvenience but as I cannot reproduce it in a simple tool, please don't bother anymore. Greetings... Stephan

On 8/3/06, Stephan Menzel <smenzel@gmx-gmbh.de> wrote:
Am Donnerstag, 3. August 2006 17:13 schrieb Caleb Epstein: I tried to reproduce it with a simple example myself but couldn't. Everything worked just fine. The code in question was inside a daemon, so I think it must be our fault somehow.
It's the daemon's fault. Or rather it's the umask for the user id under which the daemon runs that is the problem. Jon
participants (3)
-
Caleb Epstein
-
Jonathan Franklin
-
Stephan Menzel