Hi,
On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote:
> This same issue also happens with cp(1) from coreutils.
I verified that this statement is wrong.
1) The coreutils actually check the return value of close which can be
seen on copy.c. It has precisely two calls to close and both are
checked.
2) I created a simple LD_PRELOAD library to make close fail (attached).
Running cp foo bar with this library preloaded (i.e. failing any close
with EIO) I get the following output and return value 1:
cp: closing `foo': Input/output error
This is correct behaviour. Since scp invokes cp for local copies, the
test originally submitted testcase
Michal Suchanek wrote earlier:
> $ scp /scratch/junk . ; echo $?
> 0
> $ rm junk
is wrong as well. This command would output a similar error message to
the one above. However this does not invalidate the bug immediately. To
be sure, remote transfers need to be checked as well.
A quick grep of the openssh source indicates that checking close is
overrated. Who needs errors anyway? I want that it works!!1!eleven
Helmut
CFLAGS ?= -Wall -Wextra -W -pedantic -fPIC -rdynamic
LIBS=-lc -ldl
%.o:%.c
${CC} ${CFLAGS} -c $< -o $@
closefail.so:closefail.o
${CC} ${CFLAGS} -shared -o $@ $^ ${LIBS}
closefail.o:closefail.c
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int close(int fd) {
/* just leak the fd */
static int failcount=0;
if(failcount == 0) {
const char *p;
p = getenv("CLOSEFAIL");
if(p != NULL)
failcount = atoi(p);
}
failcount -= 1;
if(failcount == 1) {
errno = EIO;
return -1;
}
if(failcount < 1)
failcount = 1;
return 0;
}
