On Wed, Feb 17, 2010 at 11:13 AM, Bruce Evans <b...@optusnet.com.au> wrote:
> On Thu, 18 Feb 2010, Bruce Evans wrote:
>
>> On Wed, 17 Feb 2010, Poul-Henning Kamp wrote:
>>
>>> Log:
>>> Mention EISDIR as a possible errno.
>>
>> It's not a possible error.
>>
>>> ...
>
> Related bug: unlink(1) bogusly prints a messages that looks like
> strerror(EISDIR). It doesn't even try unlink(2) on directories,
> but prints this message from a private string.
>
> %%%
> Script started on Thu Feb 18 05:49:45 2010
> ttyp0:b...@besplex:/tmp/z> mkdir z
> ttyp0:b...@besplex:/tmp/z> /bin/unlink z
> unlink: z: is a directory
> ttyp0:b...@besplex:/tmp/z> truss /bin/unlink z
> lstat("z",0xbfbfe840) = 0 (0x0)
> unlink: write(2,0xbfbfe0b0,8) = 8 (0x8)
> z: is a directorywrite(2,0xbfbfe0d0,17) = 17 (0x11)
>
> write(2,0x80a6753,1) = 1 (0x1)
> exit(0x1) process exit, rval = 256
> %%%
>
> Here I use /bin/unlink since the unlink in $PATH is missing the bug.
>
> /bin/unlink is a link to /bin/rm. rm(1) takes a -d flag which should
> do the right thing for unlink, but this flag is neither settable nor
> forced for unlink(1).
>
> The above behaviour of unlink(1) is not permitted by POSIX or unlink(1)'s
> man page:
>
> POSIX (old draft, no change in current version):
> %%%
> 36900 The unlink utility shall perform the function call:
> 36901 unlink(file);
> 36902 A user may need appropriate privilege to invoke the unlink
> utility.
> %%%
>
> Man page:
> %%%
> When the utility is called as unlink, only one argument, which must not
> be a directory, may be supplied. No options may be supplied in this
> sim-
> ple mode of operation, which performs an unlink(2) operation on the
> passed argument.
>
> STANDARDS
> The rm command conforms to IEEE Std 1003.2 (``POSIX.2'').
>
> The simplified unlink command conforms to Version 2 of the Single UNIX
> Specification (``SUSv2'').
> %%%
>
> Oops, the man page actually says that the arg must not be a directory.
>
> POSIX doesn't make this restriction, except by possibly requiring
> appropriate privilege, which can be interpreted as "more privilege
> than exists" if the file is a directory so as to make FreeBSD conform
> (except the error must involve unlink(1) not being invokable in this
> case :-). POSIX doesn't specify the form of the diagnostic message for
> any case.
>
> Anyway, unlink(1) shouldn't fall into rm(1)'s error handling to to
> print its diagnostic. It should use a special message (matching its
> man page) for directories, or just try unlink(2).
>
> rm(1)'s current special message should say something about directory
> removal requiring -d, and not look like strerror(EISDIR). Or since
> directory removal is prohibited by the kernel, the -d option can never
> work, so it should have been removed ~10 years ago when the kernel was
> changed to prohibit it.
1. Where is EISDIR used in rm(1)?
[garrc...@garrcoop-fbsd /usr/src/sys]$ grep EISDIR ../bin/rm/rm.c
[garrc...@garrcoop-fbsd /usr/src/sys]$ uname -a
FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #2: Wed
Feb 3 16:57:07 PST 2010
garrc...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386
2. phk's example in a latter email used unlink(2), not unlink(1).
Thanks,
-Garrett
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
