zfs discuss - Jan 2006 - pax failure on zfs

For various reasons, I have been building parts of the NetBSD "pkgsrc"
collection, running snv_28 on an Opteron (a SunFire X2100).  One of the 
builds failed, when pax got an EPERM when attempting to create a 
directory which was an existing ZFS file system root.  On a UFS file 
system, this same operation (even when the user in question would not 
have permissions to create the directory), it fails with EEXIST.

Pax fails when it sees the EPERM; I surmise (not having looked at the 
code) that it knows to ignore EEXIST in this case.  The same errors can 
be observed with mkdir(1):
> ed at newleft> mkdir /export/pkgsrc
> mkdir: Failed to make directory "/export/pkgsrc"; Permission
denied
> ed at newleft> mkdir /export/foo
> mkdir: Failed to make directory "/export/foo"; Permission denied
> ed at newleft> mkdir /usr/src/pkgsrc
> mkdir: Failed to make directory "/usr/src/pkgsrc"; File exists
> ed at newleft> mkdir /usr/src/foo
> mkdir: Failed to make directory "/usr/src/foo"; Permission denied
In both /usr/src and /export, the "pkgsrc" directory exists; in the 
/export case, it is a ZFS file system.  Similarly, both "foo" 
directories do not exist.

Is this correct behavior for ZFS, or should I file a bug?

	--Ed

Ed Gould <Ed.Gould at Sun.COM> wrote:
> For various reasons, I have been building parts of the NetBSD
"pkgsrc"
> collection, running snv_28 on an Opteron (a SunFire X2100).  One of the 
> builds failed, when pax got an EPERM when attempting to create a 
> directory which was an existing ZFS file system root.  On a UFS file 
> system, this same operation (even when the user in question would not 
> have permissions to create the directory), it fails with EEXIST.
>
> Pax fails when it sees the EPERM; I surmise (not having looked at the 
> code) that it knows to ignore EEXIST in this case.  The same errors can 
> be observed with mkdir(1):
>
> > ed at newleft> mkdir /export/pkgsrc
> > mkdir: Failed to make directory "/export/pkgsrc"; Permission
denied
> > ed at newleft> mkdir /export/foo
> > mkdir: Failed to make directory "/export/foo"; Permission
denied
> > ed at newleft> mkdir /usr/src/pkgsrc
> > mkdir: Failed to make directory "/usr/src/pkgsrc"; File
exists
> > ed at newleft> mkdir /usr/src/foo
> > mkdir: Failed to make directory "/usr/src/foo"; Permission
denied
>
> In both /usr/src and /export, the "pkgsrc" directory exists; in
the
> /export case, it is a ZFS file system.  Similarly, both "foo" 
> directories do not exist.
I reported a similar (UFS related) bug a while ago and have been told that
the implementors are not willing to return the right errno but just
one that could fit.



In my case, a UFS partition was mounted read-only and I did try to
create mkdir("/cdrom", ...) which did already exist. The errno code
was
EROFS although in case that the FS was non-readonly it would never try
to write but return EEXIST.


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  
       schilling at fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

>In both /usr/src and /export, the "pkgsrc" directory exists; in
the
>/export case, it is a ZFS file system.  Similarly, both "foo" 
>directories do not exist.
>
>Is this correct behavior for ZFS, or should I file a bug?

Sounds like a bug to me.  I think EEXIST should trump EACCES.

Also, because the manual page states:

     If path names a symbolic link, mkdir() fails and sets  errno
     to EEXIST.

but instead it fails with "EACCES" again.

It certainly should behave like other filesystems.

Casper

On Jan 2, 2006, at 8:58, Casper.Dik at Sun.COM wrote:
>
>> In both /usr/src and /export, the "pkgsrc" directory exists;
in the
>> /export case, it is a ZFS file system.  Similarly, both "foo"
>> directories do not exist.
>>
>> Is this correct behavior for ZFS, or should I file a bug?
>
>
> Sounds like a bug to me.  I think EEXIST should trump EACCES.
>
> Also, because the manual page states:
>
>      If path names a symbolic link, mkdir() fails and sets  errno
>      to EEXIST.
>
> but instead it fails with "EACCES" again.
>
> It certainly should behave like other filesystems.
CR 6368111.

	--Ed