[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Questions on the new KIO::FileJob API
From:       nf2 <nf2 () scheinwelt ! at>
Date:       2008-05-05 20:34:52
Message-ID: 481F6F6C.4010304 () scheinwelt ! at
[Download RAW message or body]

David Faure wrote:
> On Saturday 03 May 2008, Thiago Macieira wrote:
> 
> > nf2 wrote:
> > 
> > > 1) - Creating Files: Apparently FileJob in kio_file doesn't allow
> > > creating files. As there is no QIODevice::Create flag in the
> > > QIODevice::OpenMode enum, it should probably create the file on
> > > QIODevice::WriteOnly. Although i believe it would be good to have a
> > > QIODevice::Create flag which prevents overwriting by mistake. Please
> > > have a look at the GIO GFile API also...
> > > 
> > It was probably not conceived for creating files. If you're going to 
> > create one, use KIO::put.
> > 
> 
> He meant at the QIODevice API level. The API doesn't include a Create flag because,
> well, most of the time when we use WriteOnly we are fine with creating the file :)
> 

A lot of such API's provide a "fail if the file already exists" 
safeguard. O_EXCL | O_CREAT for instance. QFile/QIODevice don't. I was 
just wondering why or whether it would make sense.

> Obviously FileProtocol::open does the same, it creates when called with \
> QIODevice::WriteOnly. 

Currently it fails with KIO::ERR_DOES_NOT_EXIST. That's why i am asking. 
True, if we mimic QFile behavior then it should create the file.

> I don't see a big problem there. (and neither QIODevice nor the meaning of existing \
> methods in SlaveBase can change now anyway). 
> 

As the FileProtocol:: implementation is only partially working and i 
have the suspicion that nobody has used it yet, i guess there is some 
room for interpretation. :-) Particularly regarding my second question. 
If it's supposed to work like QIODevice::readData() and QIODevice::write 
() then it could as well read/write less than requested and instantly 
move to a seekable state again.

Cheers,
Norbert


[prev in list] [next in list] [prev in thread] [next in thread]