bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

failed test for coreutils-5.2.1 rm fail-eperm on sparc-sun-solaris2.9


From: Bert Fischer
Subject: failed test for coreutils-5.2.1 rm fail-eperm on sparc-sun-solaris2.9
Date: Sat, 11 Sep 2004 16:44:18 +0200

It is probably not a bug, but you might be interested anyway. Running
`make check' after building coreutils-5.2.1 I get a failed test for rm. 
Here is some output:

,----[ make check ]
| make  check-TESTS
| make[1]: Entering directory `/home/fischer/tmp/coreutils-5.2.1/tests/rm'
| PASS: dir-no-w
| ***************************
| NOTICE:
| ./fail-2eperm: This test is being skipped, since it works only
| when run as root.
| ***************************
| SKIP: fail-2eperm
| PASS: cycle
| PASS: i-no-r
| fail-eperm: unexpected exit status from `rm -f /tmp/.aaa';
|   got 0, expected 1
| FAIL: fail-eperm
| PASS: dangling-symlink
| PASS: rm1
| PASS: rm2
| PASS: rm3
| PASS: rm4
| PASS: rm5
| PASS: unread2
| PASS: r-1
| PASS: r-2
| PASS: r-3
| PASS: i-1
| PASS: ir-1
| PASS: f-1
| PASS: sunos-1
| PASS: deep-1
| ./hash: This test is relatively expensive, so it is disabled by default.
| To run it anyway, rerun make check with the RUN_EXPENSIVE_TESTS
| environment variable set to yes.  E.g.,
| 
|   env RUN_EXPENSIVE_TESTS=yes make check
| 
| SKIP: hash
| PASS: isatty
| ======================================
| 1 of 20 tests failed
| (2 tests were not run)
| Please report to address@hidden
| ======================================
| make[1]: *** [check-TESTS] Error 1
| make[1]: Leaving directory `/home/fischer/tmp/coreutils-5.2.1/tests/rm'
| make: *** [check-am] Error 2
`----

The situation in the /tmp-directory was something like this:

,----[ ls -al /tmp ]
| total 294690
| drwxrwxrwt   8 root     sys         1063 Aug 30 19:45 .
| drwxr-xr-x  29 root     root        1024 Aug 24 10:26 ..
| drwxrwxr-x   2 root     root         176 Jul 29 19:23 .X11-pipe
| drwxrwxr-x   2 root     root         176 Jul 29 19:23 .X11-unix
| -rw-rw-rw-   1 root     other          0 Aug 30 19:45 .aaa
| drwxrwxrwx   2 root     other        252 Aug 27 10:14 .removable
| -rw-------   1 fischer  ka          3025 Aug 20 14:45 ab2_TRa4MJ
| -rw-------   1 fischer  ka        334812 Aug 17 11:32 dtdbcache_:0
| -rw-r--r--   1 fischer  ka             0 Aug 27 10:14 sdtvolcheck11623
| -rw-r--r--   1 fischer  ka             0 Jul 29 12:31 sdtvolcheck3312
| -rw-------   1 fischer  ka            49 Aug 23 09:34 sh21330.2
| -rw-------   1 fischer  ka            50 Aug 23 09:34 sh21330.3
| -rw-r--r--   1 fischer  ka             6 Aug 17 11:32 speckeysd.lock
`----

I think the reason might be a non-POSIX system call. At least, the man
page says that unlink will remove the file in a sticky directory if
the user has write permission:

,----[ man -s2 unlink ]
| 
| System Calls                                            unlink(2)
| 
| NAME
|      unlink, unlinkat - remove directory entry
| 
| [...]
| 
| RETURN VALUES
|      Upon successful completion, 0 is returned.  Otherwise, -1 is
|      returned,  errno  is set to indicate the error, and the file
|      is not unlinked.
| 
| ERRORS
|      The unlink() and unlinkat() functions will fail if:
| 
|      EACCES
|            Search permission is denied for  a  component  of  the
|            path  prefix; write permission is denied on the direc-
|            tory containing the link to  be  removed;  the  parent
|            directory  has  the sticky bit set and the file is not
|            writable by the user; or the user  does  not  own  the
|            parent directory and the user does not own the file.
|
| [...] 
| 
| SunOS 5.9            Last change: 1 Aug 2001                    3
| 
`----

Please let me know if you require any further information.

Best regards,
Bert Fischer





reply via email to

[Prev in Thread] Current Thread [Next in Thread]