--- Jay Ts <[EMAIL PROTECTED]> wrote: > > * The corruption was missing records. It would > > interrupt the print process and the Opus analysis > > indicated hundreds of records were missing. It > would > > happen in random places in print files (hundreds > of > > megs to gigs in size), and seldomly would not > happen > > at all. > > I still don't understand! Ok, the files are not > printed > on the Samba host, they are printed through an NT > print server, correct?
Through a variety of print servers to a variety of printers, from large laser printers that print to spools of paper to washing machine-sized HP LaserJet printers. One of the queues is on NT, one (or more) is on Netware. > So are you saying that it's > files served by Samba that are being sent to the > printer, and that's where you're losing data? I think the corruption is happening in the processing of the large DB files on the new server. > [ok I just re-read your original post...] You said > that the Samba server is used as a "print spooling > area". Can you elucidate? Above. > It seems you are offering a Samba > file share, which is used by another system(s?) for > NT's printer spool files. Nothing in NT is configured to spool to that server, but somewhere along the line, files are put on that server. > There are some "dangerous" smb.conf parameters, and > AFAIK (maybe not infinitely far ;) the Samba Team > have documented that they can be misused in a way > that can result in corruption. > > Did you check the manual page for smb.conf(5), > especially for the parameters having to do with > locking, to check that you weren't doing anything > wrong? We scoured every reference to locking in the manpages, online documents, and in /usr/share/doc, which is why I think if there is a known caveat, it ought to appear somewhere. > Just to head off another bunch of comments from the > Samba Team, > please understand that just because you get a > message from Windows > that says your database is *possibly* corrupt, it > doesn't mean > that your database *is* corrupt. OK? ;-) (: We *really* did see corruption, though. > > We might reenable kernel then > > regular then level2 oplocks later to see if it was > > just one particular type. > > Pretty please! I'm really curious to find out > exactly what was happening. I'd be happy to let the group know. I'm not positive we'll reenable anything but kernel oplocks, though. We have work to do. /dev/idal __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/