The rename system call in OpenBSD will error with EACCES if you try to
rename a read only directory (test done in non-sticky dir):
$ mkdir testdir
$ chmod 555 testdir
$ mv testdir tdir
mv: rename testdir to tdir: Permission denied
$ ls -ld .
drwxr-xr-x 4 smallm smallm 512 May 7 22:12 ./
I also tried my own program to make sure this wasn't mv specific:
=======================================================================
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
int
main()
{
mkdir("testdir", 0555);
if (rename("testdir", "tdir") == -1) {
fprintf(stderr, "errno %d: %s\n", errno, strerror(errno));
}
return 0;
}
=======================================================================
$ ./a.out
errno 13: Permission denied
So I guess this is one of the ways a Unix system is allowed to work, if
I'm reading IEEE 1003.1 as intended:
"[EACCES] A component of either path prefix denies
search permission; or one of the directories containing old or new
denies write permissions; or, write permission is required and is
denied for a directory pointed to by the old or new
arguments. "
http://www.opengroup.org/onlinepubs/009695399/functions/rename.html
But should OpenBSD's man page mention the case?
$ man -c rename | col -b | grep -C2 EACCES
prefix of to does not exist.
[EACCES] A component of either path prefix denies search
permission.
[EACCES] The requested link requires writing in a directory
with a mode that denies write permission.
--
file descriptor but it does not reference a directory.
[EACCES] The from or to argument specifies a relative path but
search permission is denied for the directory which
the fromfd or tofd file descriptor, respectively,
I noticed this when wondering why test fCmd9.4 fails in the tcl test
suite and reporting its failure, after finding an old bug against
systems with similar rename behaviour:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219158&group_id=10894
As a general question of process or etiquette, would you have preferred
that I had written here first before communicating upstream?
--
Mike Small
[email protected]
