Xref: utzoo comp.unix.xenix:1283 comp.sys.att:1994
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!ho95e!catnip!ben
From: ben@catnip.UUCP (Bennett Broder)
Newsgroups: comp.unix.xenix,comp.sys.att
Subject: Re: mailx and big files
Message-ID: <545@catnip.UUCP>
Date: 6 Jan 88 04:26:12 GMT
References: <2433@dasys1.UUCP> <1988Jan4.140623.19127@lsuc.uucp>
Reply-To: ben@catnip.UUCP (Bennett Broder)
Organization: The Broder Residence, Holmdel, NJ  07733
Lines: 28

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}/