With the nftw() implementation, there was some bugginess in our exit
code that was both documented and tested. Well now I plan on fixing
that, so the documentation has been updated to state what the exit
code _should_ be, and the tests now check for the correct behavior
(meaning that they fail, for the moment).
failure. If one succeeds, one fails, and one causes an error, then the
overall result will be an error; and so on.
.P
-The \fB\-\-recursive\fR flag modifies this behavior. Due to an
-implementation detail, the recursive operation will return
-EXIT_SUCCESS even if it encounters links or inaccessible paths during
-the traversal. Beware; this means that manually supplying all children
-of a directory on the command-line does not act the same as operating
-on that directory recursively.
+When the \fB\-\-recursive\fR flag is used, the exit code is computed
+as if all affected paths were passed, depth-first, on the command-line.
compare
-# The previous test should "succeed" if we use --recursive. This is
-# buggy, but it's documented.
+# The previous test should fail, even if we use --recursive.
TESTNUM=35
TARGET="${TESTDIR}/bar"
touch "${TESTDIR}/foo"
setfacl --default --modify user:${USERS[0]}:rw "${TESTDIR}"
"${BIN}" --recursive "${TARGET}"
ACTUAL="$?"
-EXPECTED="0"
+EXPECTED="1"
compare
compare
-# And test the buggy behavior again; the previous test should return
-# success (ignoring the failure) when --recursive is used.
+# The failure should prevail when using --recursive, too.
TESTNUM=38
mkdir "${TESTDIR}/foo"
ln -s foo "${TESTDIR}/bar"
mkdir "${TESTDIR}/baz"
"${BIN}" --recursive "${TESTDIR}"
ACTUAL="$?"
-EXPECTED="0"
+EXPECTED="1"
compare