A while back, Azarah and I worked on resolving a sandbox problem related to making directories. The fix was to make the sandbox return an EEXIST if the directory exists during a mkdir, even if the mkdir attempt was outside of the sandbox. This is proper behavior. However, it doesn't work properly all of the time. The following is a proposed fix, however, it may need to be thought out a little bit more than what I have: libsandbox.c, line 477: - lstat(canonic, &st); - if (0 == errno) { + if ((0 == lstat(canonic, &st))) { Reproducible: Always Steps to Reproduce: Actual Results: You can see the effects of this at Bug #35836 Expected Results: I would expect the sandbox to always return an EEXIST, and not fail if the directory exists (this works most of the time).
I have tried the fix and it worked on my machine.
It's reasonable... You cannot assume errno is valid unless the system call returns an error condition... you're checking success in your patch... which would mean that the directory was stat'd. I'm not sure about returning EEXIST... but non-zero is probably fine as long as you set errno... which is done.
returning errno is wrong, mkdir should return -1 on failure and set errno. Things really go wrong if not. e.g. all cvs ebuilds are broken with this patch. This works: --- libsandbox.c 2004-03-22 02:40:58.000000000 +0100 +++ /home/jeffrey/libsandbox.c 2004-04-07 01:56:41.000000000 +0200 @@ -476,7 +476,7 @@ /* Check if the directory exist, return EEXIST rather than failing */ if (0 == lstat(canonic, &st)) { errno = EEXIST; - return errno; + return -1 } errno = my_errno;
I tried cvs ebuild with your patched sandbox But it failed(same error). Any idea?
the 'cvs is not creating directories one at a time' warning followed by ther 'there is already a version in foobar' error? In that case, weird, works fine here, kde-cvs is emerging fine here right now. If you get another error, try to remove your cvs repository first and check it out again.. In my case cvs had completely messed up the CVS/* directories
I encountered the error. Hmm, I'll try it again.. can anyone try it too?
Bug has been fixed and released in stable portages on or before 2.0.51-r2