Questions on the new KIO::FileJob API

nf2 nf2 at scheinwelt.at
Mon May 5 21:34:52 BST 2008


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








More information about the kde-core-devel mailing list