Dear Jeremy, I further tracked down my problem with bad file escriptors and introduced a log print as follows:
cd /usr/src/packages/BUILD/samba-2.2.3a/source/smbd/ diff -c fileio.c.orig fileio.c *** fileio.c.orig Sun Feb 3 01:46:55 2002 --- fileio.c Fri Apr 19 15:36:17 2002 *************** *** 49,54 **** --- 49,57 ---- errno = 0; } + DEBUG(1,("seek_file: fd = %d, requested pos = %.0f, new pos = %.0f\n", + fsp->fd, (double)(pos+offset), (double)seek_ret )); + if((seek_ret == -1) || (seek_ret != pos+offset)) { DEBUG(0,("seek_file: sys_lseek failed. Error was %s\n", strerror(errno) )); fsp->pos = -1; Diff finished at Mon Apr 22 09:06:45 An intersting part of the resulting log file (debug level =1 ), which shows all seek operations on our samba server shows, that occasionally seek call fail for fd==1. This is despite the fact, that other seeks on fd 1 succeed without problems. Using fd 1 seems also to be the right behaviour from the kernel/glibc, because samba closes stdin,stdout and stderr, when forking off a child for handling a client. (kernel: 2.4.16 from SuSE, glibc-2.2.4, snipped log file attached) Does anybody have a clue, what's going wrong here ? glibc doing some magic with fd==1, even if it's not associated with stdout ? A samba bug ? Regards, Wolfgang -- Dr. Wolfgang Glas EV-i Informationstechnologie GmbH. Geschäftsführer Sebastian-Kneipp-Weg 17 [EMAIL PROTECTED] A-6020 Innsbruck/Austria phone: ++43-512-284883-2 fax: ++43-512-281624-31
log.smbd.short2.bz2
Description: Binary data