Project

General

Profile

Actions

Bug #1701

closed

mkdir / returns EPERM instead of EEXIST (related to pkg_add)

Added by c.turner over 14 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hello all,

sent this to bugs@ instead of kernel@ so it gets tracked..

revamping my dev setup - which includes a number of tools which
interface with pkg_add -

long story short - anyone know where to find why in
the code 'mkdir /' fails with 'EPERM' ?

Having trouble finding this, specifically..

(yes, I tried with syscall - this is how I found the bug)

It seems like this behavior is incorrect w/r/t posix -
or at least undefined .. I'd think it should return EEXIST ..

http://www.opengroup.org/onlinepubs/000095399/functions/mkdir.html

The pkgsrc connection is that packages generated with install prefix
of '/' (e.g. for packaged config files) fail as pkg_add tries to 'mkdir
/' .. and fails for this case as it is unexpected.

I've been using packages that do this since 1.8 or so - with a hiatus
from 2.0-2.4 era - in the meantime joerg? changed the pkgsrc tools to
internally use their own mkdir implementation, but this doesn't appear
to be related, as the regular mkdir utility fails with the same error,
and the previous pkg_add implementation had similar behaviour ..

so my theory is it happened somewhere in the VFS reworking to support
hammer.. but not sure when/where.

Yes, I know it's silly to 'mkdir /' - so perhaps this should be fixed in
pkgsrc instead.. but in any case, if this isn't up to spec, it should
be fixed here also..

unfortunately dont have any other BSD based systems around at the moment
to cross check - linux reports 'EEXIST' ..

Once I know where to fix it, I have no problem working up a patch..
and if my leaf account is still functional after my journey into
the abyss I will get up to speed with git and make the commit..

just need a bit of pointers (HA!) in the right direction I suppose..

Thanks,

- Chris


Files

nlookup-mkdir.patch (952 Bytes) nlookup-mkdir.patch c.turner, 03/29/2010 02:42 AM
Actions

Also available in: Atom PDF