[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