samperi@dasys1.UUCP (Dominick Samperi) (01/02/88)
When I use mailx to send a large text file (about 50K or more) via 'mailx user < file', I get error messages of the form "can't append to /usr/mail/user" and "can't write to dead.letter", yet it turns out that the contents of the file WAS appended to /usr/mail/user, and the contents were also written to dead.letter! Furthermore, there was no corruption in either file (/usr/mail/user or dead.letter). I'm using an AT compatible, running System V/AT. Any ideas out there? -- Dominick Samperi, Manhattan College, New York, NY ...!ihnp4!cmcl2!manhat!samperi ...!ihnp4!cmcl2!phri!dasys1!samperi
dave@lsuc.uucp (David Sherman) (01/04/88)
In article <2433@dasys1.UUCP> samperi@dasys1.UUCP (Dominick Samperi) writes: >When I use mailx to send a large text file (about 50K or more) via >'mailx user < file', I get error messages of the form "can't append >to /usr/mail/user" and "can't write to dead.letter", yet it turns out >that the contents of the file WAS appended to /usr/mail/user, and >the contents were also written to dead.letter! Furthermore, there was >no corruption in either file (/usr/mail/user or dead.letter). I'm using >an AT compatible, running System V/AT. Any ideas out there? Sure. You're using a 16-bit machine, and the value for the number of bytes written is stored in a regular (short) "int" variable. Once this tops 32767, it goes negative. The code which tests for success of the write assumes that "n<0" means failure (normally -1 is returned on failure of a system call), so it tells you the write failed when in fact it worked fine. Solution, if you have source, is of course to ensure that the variable used to store the number of bytes written is a long int. David Sherman The Law Society of Upper Canada Toronto -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave Pronounce it ell-ess-you-see, please...
ben@catnip.UUCP (Bennett Broder) (01/06/88)
In article <1988Jan4.140623.19127@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: >In article <2433@dasys1.UUCP> samperi@dasys1.UUCP (Dominick Samperi) writes: >>When I use mailx to send a large text file (about 50K or more) via >>'mailx user < file', I get error messages of the form "can't append >>to /usr/mail/user" and "can't write to dead.letter", yet it turns out >>that the contents of the file WAS appended to /usr/mail/user, and >>the contents were also written to dead.letter! Furthermore, there was >>no corruption in either file (/usr/mail/user or dead.letter). I'm using >>an AT compatible, running System V/AT. Any ideas out there? > >Sure. You're using a 16-bit machine, and the value for the number >of bytes written is stored in a regular (short) "int" variable. Once this >tops 32767, it goes negative. The code which tests for success of >the write assumes that "n<0" means failure (normally -1 is returned >on failure of a system call), so it tells you the write failed when >in fact it worked fine. > >Solution, if you have source, is of course to ensure that the >variable used to store the number of bytes written is a long int. Dave hit the nail on the head, but I think the problem is in mail/rmail, not mailx. -- Ben Broder {ihnp4,rutgers} !ho95e!catnip!ben {houxa,clyde}/
jmsully@admin.UUCP (John M. Sully) (01/09/88)
In article <1988Jan4.140623.19127@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: >In article <2433@dasys1.UUCP> samperi@dasys1.UUCP (Dominick Samperi) writes: >>When I use mailx to send a large text file (about 50K or more) via >>'mailx user < file', I get error messages of the form "can't append >>to /usr/mail/user" and "can't write to dead.letter", yet it turns out [...] >Sure. You're using a 16-bit machine, and the value for the number >of bytes written is stored in a regular (short) "int" variable. Once this >tops 32767, it goes negative. The code which tests for success of >the write assumes that "n<0" means failure (normally -1 is returned >on failure of a system call), so it tells you the write failed when >in fact it worked fine. What was actually going on here was that the length of the message to be written to the specified file was held in a long, but the loop counter for the loop which wrote the characters was an int. When the message length was greater than 32767 the int went negative and, since the test was for i<k the writes continued successfully, but eventually the read returned EOF before the loop terminated. This caused an error flag to be set and blooey! your message was sent, but mail didn't know it. Dominick, we now have a fix for this available on the BBS in the support286 section. John M. Sully Microport Systems