FileStream>>nextPutAll: todo item

Hi Blair,

I've found something that looks like a reproduceable problem - that's the
good news.  The bad news is that it's a little too reproduceable for comfort
=:0

Making a long story short, routine logging that I've done for a long time
seems to be choking on a particular ME machine, resulting in an access
denied error.  I thought about Keith's report of the an incorrect error
code, but, that doesn't look like it's the problem here.  I also suspected
that I was trying to stream something that didn't like being streamed, but,
that fell through: some of the lines that are blowing up are simple strings,
and (a little more convincing) a CR.

If I'm reading things correctly, the problem always looks like this:

 File>>signalOsError
 File>>write:count:
 FileStream>>nextPutAll:

(or it might "start" with #cr, calling #nextPutAll:).  So far, I haven't
found any failed calls of #write:count: that go through #flush; but, if
that's really important, I'll take a closer look.

There are many things that could be wrong on my end, not to mention in ME,
but, FileStream>>nextPutAll: contains a #todo that mentions a possible
re-write problem.  While this is probably just an efficiency issue, could ME
be complaining about it?  Is there a way to force a re-write to find out?
Any proposed fixes looking for an alpha-tester?

One quick test would be to replace the file stream with a deaf object to see
if it fixes the doom scenario, but, it would also blind me to some real
errors that need to be fixed.  I don't simply log errors, but, also
"warnings" about suspicious conditions, etc..

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill

> ....
> There are many things that could be wrong on my end, not to mention in ME,
> but, FileStream>>nextPutAll: contains a #todo that mentions a possible
> re-write problem.  While this is probably just an efficiency issue, could
ME
> be complaining about it?  Is there a way to force a re-write to find out?
> Any proposed fixes looking for an alpha-tester?

The todo in question is referring to a small efficiency concern, in that a
benign double update of the same page of the file may occur in the case
where the write overlaps a page boundary.

Regards

Blair

Hi Blair,

> > There are many things that could be wrong on my end, not to mention in
ME,
> > but, FileStream>>nextPutAll: contains a #todo that mentions a possible
> > re-write problem.  While this is probably just an efficiency issue,
could
> ME
> > be complaining about it?  Is there a way to force a re-write to find
out?
> > Any proposed fixes looking for an alpha-tester?
>
> The todo in question is referring to a small efficiency concern, in that a
> benign double update of the same page of the file may occur in the case
> where the write overlaps a page boundary.

Fair enough, but, is there a way to either force it to happen, or at least
dectect when it does?  If so, I might subclass FileStream to add the trap to
the offending application and then either be able to correlate the occurance
with the failures, or more likely show that it comes and goes w/o incident.
The "access denied" error just strikes me as odd, and since I've seen this
only on ME, I'm wondering whether something might have changed.

A few years ago, I went through a series of problems with serial
communications (Ian might recall bailing me out of it - thanks!!!!), and
most of the trouble was due to MS gradually enforcing the specs they had
written at the beginning of Win32's existence; the code never should have
worked as it was, but it did for a while.  I want to rule out a similar kind
of problem with file privileges in this case.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]