pop-forum Possible problem using discappend
Aaron Sloman
a portion of the file has been over-written with null characters.
This is a file that is used by ved_send every time I send an email
message. A few lines are added at the end of the file, containing
copies of these lines from the message header:
The date
The To: line
The Cc: line (if present)
The Bcc: line (if present
The Subject: line
The program that appends those lines uses discappend.
I have been using it only on Linux (CentOS 5).
2.6.18-53.1.6.el5 #1 SMP Wed Jan 23 11:30:20 EST 2008
I am beginning to wonder whether there is something in discappend
that needs to be changed. This is the current definition (in
$usepop/pop/lib/auto/discappend.p )
compile_mode:pop11 +strict;
section;
include sysdefs.ph;
define global discappend(file);
lvars file, dev;
unless isdevice(file ->> dev) then
if isword(file) then file sys_>< pop_default_type -> file endif;
sysopen(file, 2, false) -> dev;
endunless;
if dev then
#_IF DEF UNIX or DEF WIN32
sysseek(dev, 0, 2);
#_ELSE
lconstant LEN = 512;
lvars buff = device_init_buffer(dev, LEN);
while sysread(dev, buff, LEN) == LEN do
/* nothing */
endwhile;
#_ENDIF
endif;
discout(dev or file);
enddefine;
endsection;
======================================
This uses sysseek, which is defined thus:
;;; ------------------- SEEK ON A DEVICE ---------------------------------
#_INCLUDE 'declare.ph'
#_INCLUDE 'io.ph'
;;; ---------------------------------------------------------------------
section $-Sys => sysseek;
define sysseek(dev, _pos, _mode);
lvars dev, _pos, _mode, _retpos = false;
if isboolean(_mode) then
;;; 4-th arg true means return position after seek
_mode -> _retpos; _pos -> _mode; dev -> _pos;
-> dev
endif;
Check_device(dev, true);
Check_integer(_pos, false);
Check_integer(_mode, 0);
if _mode fi_> 2 then
_mode fi_- 3 -> _mode;
_pos fi_* 512 -> _pos
endif;
fast_apply(dev, _pos, _mode, dev!D_SEEK);
unless _retpos then -> endunless
enddefine;
endsection; /* $-Sys */
===================
This line worries me:
_pos fi_* 512 -> _pos
Where would 512 come from? Is that an operating system constant?
I assume this invokes an operating system 'seek' routine.
'MAN lseek' ends with the following:
Note that file descriptors created by dup(2) or fork(2) share the cur-
rent file position pointer, so seeking on such files may be subject to
race conditions.
since ved_send forks in order to invoke sendmail I wonder if that
could have anything to do with this problem.
I may be the last person in the world using Ved for sending mail?
I am going to try setting ved_send_wait to true, to see if that
makes a difference.
Aaron Sloman
> Date: Fri, 2 May 2008 18:28:53 +0100
>
> In the last few months I have several times found a file corrupted:
> a portion of the file has been over-written with null characters.
>
> This is a file that is used by ved_send every time I send an email
> message. A few lines are added at the end of the file, containing
> copies of these lines from the message header:
>....
> The program that appends those lines uses discappend.
> I have been using it only on Linux (CentOS 5).
> 2.6.18-53.1.6.el5 #1 SMP Wed Jan 23 11:30:20 EST 2008
> ....
> I am beginning to wonder whether there is something in discappend
> that needs to be changed.
>......
>
> This uses sysseek, which is defined thus:
>...
>
> This line worries me:
> ...
> _pos fi_* 512 -> _pos
>
> Where would 512 come from? Is that an operating system constant?
Steve Isard sent this response:
> On Fri, 2 May 2008, Aaron Sloman wrote:
>
> (snip)
> > if _mode fi_> 2 then
> > _mode fi_- 3 -> _mode;
> > _pos fi_* 512 -> _pos
> > endif;
> (snip)
> > This line worries me:
> >
> > _pos fi_* 512 -> _pos
> >
> > Where would 512 come from? Is that an operating system constant?
>
> lseek and friends use the mode values 0,1,2 to indicate whether the
> seek should be calculated (as a number of bytes) from the beginning, the
> current position, or the end of the file. It appears that sysseek uses
> mode values 3,4,5 to indicate that the seek should be calculated as a
> number of 512 byte blocks (although ref sysseek doesn't document such
> behaviour).
>
> In any case, the call to sysseek in discappend is
>
> > sysseek(dev, 0, 2);
>
> hence _mode isn't greater than 2 in this case, and the suspect line
> shouldn't be reached. And even if it were, _pos is 0, and
> multiplication by 512 wouldn't change it.
>
> So it looks as if the problem lies elsewhere.
Sounds right.
Anyhow, I have altered the default value of ved_send_wait, used by
ved_send, from false to true, to reduce dependence on vfork.
So I guess I have to wait a month or two to see if the problem
recurs. I get the problem only when sending mail on our departmental
system which has a complex network of desktop machines, compute
servers (also used for remote logins as I am doing now), NFS file
servers (shared between solaris, linux and windows users), and
various other machines providing services. So it could be some sort
of timing problem that would not arise in simpler environments.
I don't get the problem when sending mail from my linux PC at home.
A couple of decades ago, making ved_send_wait false enormously
speeded up sending of mail in Ved. Now it doesn't seem to make any
noticeable difference whether it is true or false. If true, the
poplog process waits for the forked process using sendmail to
complete before continuing.
Aaron