Steve Clark wrote:
> > , bloats the code
>
> how? is there redundant code for the second pass?
The second pass code is all bloat - we don't need it!!
> file access is slow, and you may not always have a disk to write to.
> It'd be nice if you just wrote to memory if possible, and only went to
> disk if necessary. I think this general problem has been solved and an
> abstraction for a temp file exists, so you don't have to sweat the
> details. But I don't recall the class name for temp files, or even if
> it's in the tree yet.
The code in the routine in question already creates a temp file for the post
data, so on systems that are totally "read-only" I wouldn't make the problem
any worse (but I thought the Mozilla goal was that Mozilla itself should be
able to run from a read-only media (such as cdrom), but that /tmp or the likes
would still exist in its usual writeable form).
> > This means that we don't need to rely upon
> > stat to get any input file size
>
> what is the issue with "stat"?
Details are in the bug report, but basically you can't rely on stat to always
return a value. If you stat /dev/tty on Linux you get back 0 (success) and
st_size is zero. Other operating systems have other quirks in this area.
OpenVMS for example returns the actual number of bytes in the file, including
any meta-data, and so for some record formats this is not the same as number
of bytes you will read().
> If the main issue really is locking the file, maybe we should pursue
> that instead. Copying a large data set could be very expensive.
The main issue is not locking the file, its the fact that stat can't be relied
upon. The window that exists whereby if the file contents change we'll lie
about Content-length is just another problem that we can/should also fix.
As ugly as copying the file is, the idea of locking the file by opening it for
exclusive write access is no better in my mind. In fact I think its worse
since you introduce a window during which if some other app tries to open the
file it will fail. This is bad.
A temp file class that only writes to disk if need be (basically a pipe with
no size limitation) would make this implementation and execution much more
elegant. You say something exists much isn't checked in yet?
Colin.
