Release the file created by QFile

Question

CASE

my Qt application create a file by QFile
I intend to use dll to read this file

SYMPTOM

dll cant use it, because it's occupied by the QAppilcation

ATTEMPT

I tried file.close() to release the file, does not work;
I tried other application to read this file, same symptom as occupied, which means dll is fine.

So, What can I do to release a file that is already created and closed by QFile?

Release the Qt file

    void MainWindow::creatFile(){
       QFile file("1.dat");
       if (!file.open(QIODevice::WriteOnly | QIODevice::Text))
           return ;

       if(!file.exists())
           return;

       QTextStream out(&file);
       out << "test" <<endl;

       out.flush();
       file.close(); // .~QFile() is not needed at all.
       return;
   }

convert QString to Character(Fortran)

typedef void (* myfun)(char string[255]); //How Qt pass character to Fortran dll

//QString-> std::string -> char* 
std::string fileName_std = fileName.replace("/","\\").toStdString();
const char* fileName_cstr = fileName_std.c_str();

char fileName_For90[255];
int length = sizeof(fileName_For90); 

//fill the left nulls of char with blanks which are required in Fortran
strcpy(fileName_For90,fileName_cstr);
for(int i = strlen(fileName_For90); i < length; i++){
    fileName_For90[i] = ' '; 
}

Is the QFile object used for writing destroyed at the point where the DLL wants to read the file? — Frank Osterfeld, Oct 30 '13 at 05:06
@FrankOsterfeld . the sequence is (1) QTextStream write all I want into the Qfile obeject(file1), and at this point file1 should be released by QApplication. (2) QLibray load the DLL (3) dll read the file1 to calculate or do other things. Your "destroy" means "close" or "remove", or out of the memory? — Fay100, Oct 30 '13 at 05:33
~QFile() being called, i.e. the QFile object going out of scope if created on the stack, or being deleted if on the heap. — Frank Osterfeld, Oct 30 '13 at 05:40
@FrankOsterfeld isn't it called when we use QFile::close()? `QFile::~QFile () Destroys the file object, closing it if necessary.` — Fay100, Oct 30 '13 at 06:21
@FrankOsterfeld thanks,you are right. ~QFile() lets the file go. but the application crashes:( ...I tested the simplest codes(just add it into the Question), still crash with error**pc 0x4c in read in psymtab, but not in symtab**, any idea? — Fay100, Oct 30 '13 at 09:59
You don't have to call ~QFile explicitly. Leaving creatFile() does that for you (as stack variables are destroyed at the end of the block). Your code looks correct without the ~QFile call. — Frank Osterfeld, Oct 30 '13 at 10:36
More than that, you must (almost) never call destructor explicitly. It's dangerous and awkward. The rest of code is quite correct. Probably the cause is somewhere else. May be this file is still opened in another part of your app. — Pavel Strakhov, Oct 30 '13 at 11:16
@PavelStrakhov ur right, the qt code is fine. error in Fortran dll. However, it works fine in Fortran console application:(... Appreciate your advice, thanks. — Fay100, Oct 31 '13 at 09:03
@VladimirF *The SHARE specifier indicates whether file locking is implemented while the unit is open.* It determines whether other application/implemention could read/write in the initial file. — Fay100, Oct 31 '13 at 10:20
Well, you didn't even include the error message, let alone enough code. What are we supposed to guess from that? — Vladimir F Героям слава, Nov 02 '13 at 11:18
@VladimirF well, the error is always "can't read or can't open". sorry I missed a "d" in "solve". Just solveD it....Thanks very much, next time I'll do what you said. And I just updated the solved ones in the Qs. — Fay100, Nov 02 '13 at 11:30

score 0 · Answer 1 · edited May 23 '17 at 12:02

(This question has answers in the comments and edited into the question. The question has repeated edits and is more like a blog than a question and it is no longer clear what the question was, whereas SO expects a clear question and a clear answer. See Question with no answers, but issue solved in the comments (or extended in chat). I'm putting this community Wiki Answer so that the question is recorded as answered, however I'm finding it hard to extract an answer from all that chat and edit.)

The OP wrote:

Here is what I get during solving:

.close() actually does close the file. And .flush() might be needed as you can find details here QFile::flush() vs QFile::close()

the real problem lies in converting QString to Character in Fortran.

guitarpicva · Answer 2 · 2020-05-08T11:33:14.563

I would suggest using QSaveFile. I have run into many instances where trying to create a file in place, and then immediately referencing and using it can cause this problem. QSaveFile creates the file in a temp space and moves it to it's final destination. This seems much more deterministic when other functions or signaled processes need to work on the file. This is partciularly true of QFileSystemWatcher.

void MainWindow::createFile(){
   QSaveFile file("1.dat");
   if (!file.open(QIODevice::WriteOnly | QIODevice::Text))
       return ;

   if(!file.exists())
       return;

   QTextStream out(&file);
   out << "test" <<endl;


   file.commit(); // .~QFile() is not needed at all.
   return;

}

Release the file created by QFile

2 Answers2