Questions on the new KIO::FileJob API

[Allan Sandfeld Jensen]

On Sunday 27 July 2008, Vlad wrote:
> Hi,
>
> --- On Sun, 7/27/08, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> > > > No. A read can result in any number data() emits.
> >
> > For files
> >
> > > > it will usually be
> > > > only one, but for streams it can be multiple.
> > >
> > > Does FileJob::write() work the same way? In other
> >
> > words, do we have to
> >
> > > check whether bytes_written == the number of bytes
> >
> > sent, and if not, then
> >
> > > attempt again to write what is left over?
> >
> > No you don't have to try again. It does the retries
> > internally
>
> This difference between FileJob::read() and FileJob::write() gets
> confusing. I suggest _not_ explicitly giving assurance that everything will
> be written at once, even though most KIO slaves will retry internally. It
> won't hurt client apps to check whether everything was indeed written and
> to prepare to write the leftover again if needed.
>
Well, okay technically speaking there is no reassurance, but if write or read 
fails to complete it is highly unlikely that retrying will help. So the 
client should just accept it and report the error.

> This way, the behaviors of FileJob::read() and FileJob::write() remain
> consistent with each other and with POSIX read() and write(), which don't
> guarantee atomicity either (see write_all() in
> kdelibs/kioslave/file/file.cpp).
>
There is something wrong with the way write_all is used. FileJob::write should 
catch the return value and emit it as written(), and if the size is smaller 
than data.size() follow up with the error that prevented completion.

`Allan