GNU bug report logs - #21534
Bug in mkdir?!

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Unger <sebunger44 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Bug in mkdir?!
Date: Tue, 22 Sep 2015 22:29:44 +1200

[Message part 1 (text/plain, inline)]

Hi,

I'm working on a little project of mine involving a Fuse file system on
Linux. I'm having a problem where mkdir from coreutils fails with
Permission denied while mkdir from busybox works.

I'm running the command *mkdir -p a/b/c* and I get the following strace
output (showing only the relevant lines at the end):
































*umask(0)                                = 022mkdir("a",
0755)                        = 0open("a",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)open("/usr/share/locale/locale.alias",
O_RDONLY|O_CLOEXEC) = 3fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...})
= 0mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f6a86f20000read(3, "# Locale name alias data base.\n#"..., 4096) =
2570read(3, "", 4096)                       =
0close(3)                                = 0munmap(0x7f6a86f20000,
4096)            =
0open("/usr/share/locale/en_NZ/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or
directory)open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en_NZ/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo",
O_RDONLY) = 3fstat(3, {st_mode=S_IFREG|0644, st_size=619, ...}) =
0mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f6a86f20000close(3)                                =
0open("/usr/lib/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such
file or directory)write(2, "mkdir: ", 7mkdir: )                  =
7write(2, "cannot create directory \342\200\230a\342\200\231", 31cannot
create directory ‘a’) =
31open("/usr/share/locale/en_NZ/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)open("/usr/share/locale/en/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en_NZ/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)write(2, ": Permission
denied", 19: Permission denied)     = 19write(2, "\n",
1)                       = 1close(1)                                =
0close(2)                                =
0exit_group(1)                           = ?+++ exited with 1 +++*
Please note that while the creation of directory 'a' succeeds, the
directory is created by the fuse with mode 0311 (-wx--x--x) and as such the
open call following the mkdir fails as expected.
If I try to simulate this on a normal file system by setting the umask to
0466, I get the following strace output:













*umask(0)                                = 0466mkdir("a",
0311)                        = 0open("a",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)chdir("a")                              = 0mkdir("b",
0311)                        = 0open("b",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)chdir("b")                              = 0mkdir("c",
0311)                        = 0close(1)                                =
0close(2)                                =
0exit_group(0)                           = ?+++ exited with 0 +++*
I.e. the open still fails but apparently mkdir can live with it.  Since it
also works on my fuse if I set the umask to 0466, I conclude that mkdir
inspects the umask to see if it expects to be able to open the directory?!
That sounds like a race to me since anything may change the mode of the
directory between the mkdir and open calls even on a normal FS and even
more so on a networked file system. Why is it trying to open the directory
in the first place? Shouldn't it just chdir into it and carry on?

Is this a bug or expected behaviour? Any ideas as to how to make mkdir
behave?

Cheers,
Seb

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.