I noticed that there were two newly-failing rm-related tests on Solaris 10. Here's the fix:
>From 623add906d554434a232d890c92b5e4ff21a1d47 Mon Sep 17 00:00:00 2001 From: Jim Meyering <[email protected]> Date: Wed, 19 Sep 2012 09:35:12 +0200 Subject: [PATCH] rm: be even more careful when using a replacement errno value * src/remove.c (excise): The adjustment in commit v8.19-107-gccbd3f3 made "rm -rf unreadable-dir" diagnostics worse on Solaris 10: -rm: cannot remove 'a': Permission denied +rm: cannot remove 'a': File exists That happened because there, unlinkat fails with EEXIST, given an unreadable directory, which made the two tests, tests/rm/unread2 and tests/rm/unreadable fail. Accommodate that case, too. --- src/remove.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/remove.c b/src/remove.c index a141718..8385012 100644 --- a/src/remove.c +++ b/src/remove.c @@ -393,11 +393,13 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir) return RM_OK; /* When failing to rmdir an unreadable directory, we see errno values - like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic. - When that happens and the errno value from the failed open is EPERM - or EACCES, use the earlier, more descriptive errno value. */ + like EISDIR or ENOTDIR (or, on Solaris 10, EEXIST), but they would be + meaningless in a diagnostic. When that happens and the errno value + from the failed open is EPERM or EACCES, use the earlier, more + descriptive errno value. */ if (ent->fts_info == FTS_DNR - && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR) + && (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR + || errno == EEXIST) && (ent->fts_errno == EPERM || ent->fts_errno == EACCES)) errno = ent->fts_errno; error (0, errno, _("cannot remove %s"), quote (ent->fts_path)); -- 1.7.12.503.g5976753
