On 05/18/2018 04:57 PM, alexander golks wrote:
the QFile::write call returns with no error, i called GetLastError() after the
QFile::write() and got 183.
the file is written up to ~30MB, and suddenly already exists?
i am pretty sure, the file doesn't exist prior the call.
First: are you runn
Am Thu, 17 May 2018 07:56:19 -0700
schrieb Thiago Macieira :
> On Thursday, 17 May 2018 07:02:17 PDT alexander golks wrote:
> > i have at least compiled 5.6.4 now, but i can not produce the error with my
> > qt5core. using 5.6.3 from qt, error exists. using mine, does not exist...
> >
> > getting
On Thursday, 17 May 2018 22:23:29 PDT alexander golks wrote:
> the QFile::write call returns with no error, i called GetLastError() after
> the QFile::write() and got 183. the file is written up to ~30MB, and
> suddenly already exists?
If there was no error reported, trying to get the error state
Am Thu, 17 May 2018 10:31:55 -0500
schrieb Roland Hughes :
> On 05/17/2018 09:11 AM, alexander golks wrote:
> >> my code was:
> >>qint64 res = f.write(data);
> > just for the curious ones:
> >
> > i have at least compiled 5.6.4 now, but i can not produce the error with my
> > qt5core.
> > u
On 05/17/2018 09:11 AM, alexander golks wrote:
my code was:
qint64 res = f.write(data);
just for the curious ones:
i have at least compiled 5.6.4 now, but i can not produce the error with my
qt5core.
using 5.6.3 from qt, error exists. using mine, does not exist...
getting the error code
On Thursday, 17 May 2018 07:02:17 PDT alexander golks wrote:
> i have at least compiled 5.6.4 now, but i can not produce the error with my
> qt5core. using 5.6.3 from qt, error exists. using mine, does not exist...
>
> getting the error code directly after the f.write(data) gives me error code
> 1
Am Thu, 17 May 2018 16:02:17 +0200
schrieb alexander golks :
> Am Fri, 11 May 2018 08:11:04 +0200
> schrieb alexander golks :
>
> > my code was:
> > qint64 res = f.write(data);
>
> just for the curious ones:
>
> i have at least compiled 5.6.4 now, but i can not produce the error with my
>
Am Fri, 11 May 2018 08:11:04 +0200
schrieb alexander golks :
> my code was:
> qint64 res = f.write(data);
just for the curious ones:
i have at least compiled 5.6.4 now, but i can not produce the error with my
qt5core.
using 5.6.3 from qt, error exists. using mine, does not exist...
getting
On 05/16/2018 06:04 AM, Thiago Macieira wrote:
Ok, so not the standard C library. But it is still the case for POSIX and
Win32.
In fact, the man page for write(2) says specifically
[...] It is not an error if this number is smaller
than the number of bytes requested; this may
Am Mon, 14 May 2018 08:45:06 -0700
schrieb Thiago Macieira :
> ...
>
> It's a matter of perspective. As seen in this thread, in some situations
> failing to write everything is an unrecoverable situation. That is the case
> here: QDataStream cannot recover from a partial write.
>
> We could lo
On Monday, 14 May 2018 09:17:42 PDT Roland Hughes wrote:
> > ?That is simply incorrect. It might not be how you would like it to
> > behave,
> > however it is the norm that short writes are allowed and should be handled
> > by the callee. This is the case in POSIX, the C standard library etc. I'm
>
On 05/14/2018 10:54 AM, Richard Moore wrote:
On Sat, 12 May 2018 at 15:45, Roland Hughes
wrote:
Any time a write comes up short, it is an error.
?That is simply incorrect. It might not be how you would like it to behave,
however it is the norm that short writes are allowed and should be han
On Monday, 14 May 2018 00:32:38 PDT alexander golks wrote:
> > int QDataStream::writeRawData(const char *s, int len)
> > {
> >
> > CHECK_STREAM_WRITE_PRECOND(-1)
> > int ret = dev->write(s, len);
> > if (ret != len)
> > q_status = WriteFailed;
> > return ret;
> >
> > }
>
2018-05-14 1:29 GMT+02:00 Thiago Macieira :
> On Sunday, 13 May 2018 09:32:23 PDT Elvis Stansvik wrote:
>> QDataStream can operate
>> fine on an QIODevice that does partial writes (like QFile).
>
> No, it cannot. If there's a failure to write, the stream is corrupt and
> unrecoverable.
Yes of cour
Am Sun, 13 May 2018 23:50:20 -0700
schrieb Thiago Macieira :
> On Sunday, 13 May 2018 23:28:47 PDT alexander golks wrote:
> > > In fact, QDataStream can't recover from any errors.
> >
> > as you've said, my origin problem is no error.
> > wouldn't it be possible for QDataStream to handle this n
On Sunday, 13 May 2018 23:28:47 PDT alexander golks wrote:
> > In fact, QDataStream can't recover from any errors.
>
> as you've said, my origin problem is no error.
> wouldn't it be possible for QDataStream to handle this no-errors, too?
It already does.
int QDataStream::writeRawData(const char
Am Sun, 13 May 2018 16:29:48 -0700
schrieb Thiago Macieira :
> On Sunday, 13 May 2018 09:32:23 PDT Elvis Stansvik wrote:
> > QDataStream can operate
> > fine on an QIODevice that does partial writes (like QFile).
>
> No, it cannot. If there's a failure to write, the stream is corrupt and
> unr
On Sunday, 13 May 2018 23:02:56 PDT alexander golks wrote:
> still this makes QFile unusable with QDataStream, doesn't it?
> isn't the documentation for QIODevice::writeData not correct then?
No more so than any other QIODevice. If QFile fails to write for some reason,
then QDataStream can't reco
Am Fri, 11 May 2018 08:34:09 -0700
schrieb Thiago Macieira :
> On Friday, 11 May 2018 04:08:48 PDT alexander golks wrote:
> > > It is not silent, you have the return value so you can detect when the
> > > number of written bytes is not equal to the size of the data.
> >
> > the error is 0. and
On Sunday, 13 May 2018 09:32:23 PDT Elvis Stansvik wrote:
> QDataStream can operate
> fine on an QIODevice that does partial writes (like QFile).
No, it cannot. If there's a failure to write, the stream is corrupt and
unrecoverable.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
2018-05-13 18:03 GMT+02:00 Elvis Stansvik :
> 2018-05-13 14:58 GMT+02:00 william.croc...@analog.com
> :
>>
>>>
>>> That is simply incorrect. It might not be how you would like it to behave,
>>> however it is the norm that short writes are allowed and should be handled
>>> by
>>> the callee. This is
2018-05-13 14:58 GMT+02:00 william.croc...@analog.com
:
>
>>
>> That is simply incorrect. It might not be how you would like it to behave,
>> however it is the norm that short writes are allowed and should be handled
>> by
>> the callee. This is the case in POSIX, the C standard library etc. I'm
>>
That is simply incorrect. It might not be how you would like it to behave,
however it is the norm that short writes are allowed and should be handled by
the callee. This is the case in POSIX, the C standard library etc. I'm afraid,
you'll simply have to learn to live with it - an easy solution
On Saturday, 12 May 2018 10:08:47 PDT Thiago Macieira wrote:
> No, partial writes are success, so long as they report how much was
> successful. This is the case as well for write(2) and WriteFile.
Note also how this applies to sockets, which use write(): partial writes are a
success, so the sock
On Saturday, 12 May 2018 07:18:03 PDT Roland Hughes wrote:
> On 05/12/2018 08:57 AM, interest-requ...@qt-project.org wrote:
> > On Thursday, 10 May 2018 23:11:04 PDT alexander golks wrote:
> >> i think it "silently" breaks here without setting error condition on the
> >> QFile when hitting errors o
On Sat, 12 May 2018 at 15:45, Roland Hughes
wrote:
> Any time a write comes up short, it is an error.
>
That is simply incorrect. It might not be how you would like it to behave,
however it is the norm that short writes are allowed and should be handled
by the callee. This is the case in POSIX,
On 05/12/2018 08:57 AM, Thiago Macieira wrote:
On Friday, 11 May 2018 04:08:48 PDT alexander golks wrote:
It is not silent, you have the return value so you can detect when the
number of written bytes is not equal to the size of the data.
the error is 0. and errorString() is "no error", too.
On 05/12/2018 08:57 AM, interest-requ...@qt-project.org wrote:
On Thursday, 10 May 2018 23:11:04 PDT alexander golks wrote:
i think it "silently" breaks here without setting error condition on the
QFile when hitting errors on all chunks but the first one, thus returning a
size lower the input
On Friday, 11 May 2018 04:08:48 PDT alexander golks wrote:
> > It is not silent, you have the return value so you can detect when the
> > number of written bytes is not equal to the size of the data.
>
> the error is 0. and errorString() is "no error", too.
> so how to evaluate for error or no err
Am Fri, 11 May 2018 18:05:11 +0800
schrieb Elvis Stansvik :
> Not sure why you bring up this piece of MS docs, when this is about QFile.
this is about qfile on windows 7. the implementation is using WriteFile.
sources for documentation are in msdn, too.
this is, what its about.
> It is not sile
2018-05-11 10:03 GMT+02:00 alexander golks :
> Am Thu, 10 May 2018 23:32:14 -0700
> schrieb Thiago Macieira :
>
>> On Thursday, 10 May 2018 23:11:04 PDT alexander golks wrote:
>> > i think it "silently" breaks here without setting error condition on the
>> > QFile when hitting errors on all chunks
Am Thu, 10 May 2018 23:32:14 -0700
schrieb Thiago Macieira :
> On Thursday, 10 May 2018 23:11:04 PDT alexander golks wrote:
> > i think it "silently" breaks here without setting error condition on the
> > QFile when hitting errors on all chunks but the first one, thus returning a
> > size lower th
On 2018/05/11 08:32, Thiago Macieira wrote:
It's not an error to not write everything.
This reply is Delphic in it's inscrutability :)
--
Regards
Alex
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/int
On Thursday, 10 May 2018 23:11:04 PDT alexander golks wrote:
> i think it "silently" breaks here without setting error condition on the
> QFile when hitting errors on all chunks but the first one, thus returning a
> size lower the input array size, which is the behaviour i see.
It's not an error t
hi,
> have you seen https://bugreports.qt.io/browse/QTBUG-56616 ?
> Your problem sounds a bit like it, although the bug should be fixed in
> Qt 5.6.3.
i have had a look now, and my file is only ~50MB in this case, so this bug
should be no problem.
besides, i am running on 5.6.3, as i haven't a
On quarta-feira, 9 de maio de 2018 02:09:23 PDT alexander golks wrote:
> i always thought, QFile::write(const QByteArray&) is meant to write all
> data.
Yes, but it also returns a qint64 that is the number of bytes written. What
did it return in your case?
--
Thiago Macieira - thiago.macieira (
Hi Alexander,
On 5/9/2018 11:09 AM, alexander golks wrote:
hi,
i recently stumbled over this situation, running on windows 7 using qt-5.6.3.
when trying to write ~50MB of data, write does not always complete, the file
does not contain all data,
yet no error is returned.
i always thought, QFil
zero byte.
>
> helmut
>
> -Ursprüngliche Nachricht-
> Von: Interest
> [mailto:interest-bounces+helmut.muelner=gmail@qt-project.org] Im Auftrag
> von alexander golks
> Gesendet: Mittwoch, 9. Mai 2018 11:40
> An: interest@qt-project.org
> Betreff: Re: [Interest] Q
Auftrag
von alexander golks
Gesendet: Mittwoch, 9. Mai 2018 11:40
An: interest@qt-project.org
Betreff: Re: [Interest] QFile::write(const QByteArray&) does not write all
data?
Am Wed, 09 May 2018 09:24:58 +
schrieb Vadim Peretokin :
yes, i tried flushing the file, too. but this changed not
Am Wed, 09 May 2018 09:24:58 +
schrieb Vadim Peretokin :
yes, i tried flushing the file, too. but this changed nothing.
i now have same do while loop as in
qint64 QFSFileEnginePrivate::nativeWrite(const char *data, qint64 len)
and this works. this writes complete file.
but i think, QFile i
Obvious question but do you flush?
On Wed, May 9, 2018 at 11:09 AM alexander golks wrote:
> hi,
>
> i recently stumbled over this situation, running on windows 7 using
> qt-5.6.3.
> when trying to write ~50MB of data, write does not always complete, the
> file does not contain all data,
> yet no
41 matches
Mail list logo
