[Samba] locking/seek Problems with SuSE-7.3 / samba-2.2.3a

wolfgang.glas at ev-i.at wolfgang.glas at ev-i.at
Thu Mar 21 07:47:07 GMT 2002


Dear samba team,

I've now found more problems, which seem to be related to my original 
posting.

Occasionally, my users get a write error and when I try to look into the 
log file of smbd, I experience, that the log file is renamed to 
log.smbd.old and the new log file is empty.

The size of the log.smbd.old i between 5MB and 6MB. Looking into 
smb.log.old I find the contents of the file, which just has been written 
by the user's application to the file in quest.
(i.e. Postscript code, if a print job is affetcted, or even other binary 
garbage)

It seems as if samba recognized after directing the data to the wrong file 
descriptor, that the log file has grown too large and started a new one.

Reading recent 2.4.19-pre4 kernel ChangeLogs, I recognized, that there are 
some patche for 2.4's lseek capabilities, so maybe my problem is related 
to a screwed up lseek call to
my 2.4.16 kernel (compare with the logs in my first mailing....), which 
leaves samba with corrupted or interchanged file handles and hence the 
data is written to log.smb instead
of the original file...

BTW, I've confirmed, that the correct compile time options 

-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE

are in samba-2.2.3a/source/Makefile in order to have off_t a 64 bit type 
and have lseek redirected to lseek64...

Did anybody else had problems with file seeking during the 2.4.x kernel 
series or does anybody know, how seriously broken lseek is in the 
questionable kernels?

So thanks for any comments or help,

    Regards,

     Wolfgang 

--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas at ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31





More information about the samba mailing list