Is there another way to convet QFile to File? Different than this:
QFile myFile("goforward.raw");
int FileDescriptor = myFile.handle();
FILE* fh = fdopen(FileDescriptor, "rb");
We had very strange problems with our application and finally traced it to the QFile/fdopen issue:
void foo(QString filename)
{
QFile qf(filename);
qf.open(QIODevice::ReadOnly);
int fd = qf.handle();
FILE* f = fdopen(fd, "rb");
// do some stuff with f
fclose(f); // !!! undefined behaviour !!!
}
The problem with this code is that fclose(f) is called before the QFile object is destroyed, which is the wrong order: QTBUG-20372
...so either destroy the QFile object before calling fclose() or duplicate the file descriptor returned by QFile::handle():
void foo(QString filename)
{
QFile qf(filename);
qf.open(QIODevice::ReadOnly);
int fd = qf.handle();
FILE* f = fdopen(dup(fd), "rb"); // !!! use dup()
// do some stuff with f
fclose(f); // correct
}
P.S.: Those strange problems with our app showed up only on very few systems by a 10 second delay between a return statement at the end of a function and the actual return from that function. It was really weird. So this is an example of an "undefined behaviour" manifested in the real world :o)
I think you already know that you have the various open, read, etc. methods in QFile. That said, if the file is not opened, then the handle method returns an error.
QFile myFile("goforward.raw");
myFile.open(QIODevice::ReadOnly);
int fileHandle = myFile.handle();
After that, you might reopen it with:
FILE* fh = fdopen(fileHandle, "rb");
If you have the file name, why don't you simply use
QFile *file = fopen(filename.toLocal8Bit().data(), "rb");
?
Isn't it way simpler than creating the QFile, opening it, retrieving the handle, etc.?
And it is pretty bug-free...
Related
Years ago I created a C++ function using FILE to create bitmap files. Recently (not sure when or why) this code is now failing when opening the file. The problem is with the open call ...
file_ptr = fopen("ScreenShots/Screenshot1.bmp", "wb");
Currently this results in an error 13, permission denied error. Change the filename extension to something else and the fopen works fine. For example,
file_ptr = fopen("ScreenShots/Screenshot1.bm2", "wb");
The file saves correctly and when changing the extension back to BMP I can display the file correctly in Paintshop.
Did a quick check using ofstream and same problem.
Any ideas why I get a permission denied error when trying to open BMP files to write data? For information I am using Visual Studio Community 2017 on Windows 10.
To give the complete section of code ...
BITMAPFILEHEADER bitmap_header;
BITMAPINFOHEADER bitmap_info;
FILE *file_ptr;
unsigned int count;
unsigned char tempRGB;
char filename[256];
bool finished;
// CREATE A UNIQUE FILENAME
count = 1;
finished = false;
do
{
// CREATE NAME
sprintf(filename, "ScreenShots/Screenshot%d.bmp", count);
// CHECK IF FILE EXISTS
errno = 0;
file_ptr = fopen(filename, "rb");
if (file_ptr)
{
// FILE EXISTS
fclose(file_ptr);
count = count + 1;
}
else
{
// UNIQUE FILENAME
file_ptr = fopen(filename, "wb");
if (file_ptr == NULL)
{
// UNABLE TO OPEN FOR WRITING - GIVE UP
// (USING OWN LOGGING CLASS)
jalog.log("\nERROR on Screenshot >");
jalog.log(filename);
jalog.log("< >");
jalog.log((short)errno);
return;
}
finished = true;
}
}
while (finished == false);
I've managed to find the issue ... Avast antivirus. I noticed that trying to do an open action for a BMP file took a few seconds while opening any other file type (successfully or unsuccessfully) was instantaneous. As something similar happens when running new programs I tried disabling all the Avast shields and I could successfully create a BMP file using the existing code.
For my own personal use I can whitelist my own programs, but annoying if I get to distributing the program to other people.
Thanks for the help ... and sorry for raising a C++ issue that in the end had nothing to do with C++!
I need to log some text messages to a file with following requirements :
Each text messages is written in a new line at the end of the file.
Be reasonably sure that each message was correctly written to the file.
So far, the function is using QTextStream and QFile:
bool FileManager::appendLine(const QString &line)
{
if(!m_file.open(QIODevice::Append | QIODevice::Text)) // m_file is a QFile
return false;
QTextStream ts(&m_file);
ts << line << endl;
bool status = (ts.status() == QTextStream::Ok);
m_file.close();
return status;
}
Point 1 is satisfied but i have doubts about Point 2.
Even Qt Doc says that it is sufficient to close() the QFile to flush all its internal buffers :
void QFileDevice::close()
Reimplemented from QIODevice::close().
Calls QFileDevice::flush() and closes the file. Errors from flush are ignored.
What about the internal buffer of the QTextStream ?
Is it necessary to call QTextStream::flush() before closing the file ?
About Point 2, i guess that reading back the line just after it has been written would be the only way to be 100% sure of that. (for example a power failure may occur while the kernel has still datas in its buffers )
Thanks.
In your case, its not, because you are appending &endl in each write!
Writting &endl to the QTextStream writes '\n' to the stream and flushes the stream. It is Equivalent to: stream << '\n' << flush;
Further, when QTextStream is flushed due to &endl, it will empty all data from its write buffer into the device and call flush() on the device.
While this particular code will work because operations with QTextStream end with an endl, it's still better to ensure that QTextStream is completely and utterly finished working with the file when you close it. Just use scopes.
bool FileManager::appendLine(const QString &line)
{
if(!m_file.open(QIODevice::Append | QIODevice::Text)) // m_file is a QFile
return false;
bool status {false};
{
QTextStream ts(&m_file);
ts << line << endl;
status = (ts.status() == QTextStream::Ok);
}
m_file.close();
return status;
}
For example, I have some arrays of filenames:
char arr[N] = ["FILENAME0", "FILENAME1", "FILENAME2", "FILENAME3", "FILENAME4", ...]
How can I write a function which depends on N will fopen and fclose N files?
switch-case and if-elif-else are straightforward, but require a lot of conditions and N already should be known (N will pass in runtime from stdin).
For-loop is not suitable here because it will open and close step by step. I want that at the beginning, function will fopen N files, then all these N files descriptors should be available in memory and only then close N files.
I expect that if N == 1 function will behave like:
int func ()
{
FILE *fp = fopen(arr[0]);
fclose(fp);
return 0;
}
or if N == 3:
int func ()
{
FILE *fp = fopen(arr[0]);
FILE *fp1 = fopen(arr[1]);
FILE *fp2 = fopen(arr[2]);
fclose(fp);
fclose(fp1);
fclose(fp2);
return 0;
}
Just store your FILE*s into a std::vector and close them with a second loop:
void func(const std::vector<std::string>>& filenames) {
std::vector<FILE*> fds;
for (const std::string& filename : filenames) {
fds.push_back(std::fopen(filename.c_str(), "w"));
}
// Work with the file descriptors however you want
for (FILE* fd : fds) {
std::fclose(fd);
}
}
If you do anything that could throw an exception between when you open the files and when you close them then you may want to use an exception-safe wrapper, rather than closing the FILE*s manually:
void func(const std::vector<std::string>>& filenames) {
std::vector<std::unique_ptr<FILE, int(*)(FILE*)>> fds;
for (const std::string& filename : filenames) {
fds.emplace_back(std::fopen(filename.c_str(), "w"), std::fclose);
}
// Work with the file descriptors however you want. To get
// the raw FILE* use fds[i].get()
// std::unique_ptr will call its deleter (std::fclose in this case)
// on its managed pointer in its destructor, so there's no need to
// manually close them
}
AFAIK, there isn't a possible solution of shortening FILE *fp = fopen(arr[0]); and so on, on C++. You are stuck using the if-elif-else clause for both opening the file and closing it.
I was doing some simple read/write operations on files using MS Visual Studio. Here is a simplified version of the code I wrote:
#include <cstdio>
#include <cstring>
void write_into_file(const char* filename);
int main()
{
write_into_file("settings.ini");
write_into_file("com4.ini");
return 0;
}
void write_into_file(const char* filename)
{
FILE* f = std::fopen(filename, "wb");
const char* text = "Some text I want to write...";
std::fwrite(text, 1, strlen(text), f);
std::fclose(f);
}
Whenever I run the program, it gets stuck and does not end. I debugged the code and traced into it. Turned out that all parts of the code are okay and run without any problems, except the line that contains fclose. I mean, the debugger gets stuck when it reaches that line. Why this happens and what is the problem?
EDIT :
I suspected that the problem is with the name of files, specially com4.ini. So I changed the code as follows:
#include <fstream>
#include <sys/stat.h>
void write_into_file(const char* filename)
{
std::ofstream fp(filename, std::ios::out);
if (fp.is_open())
fp.close();
struct stat info;
if (stat(filename, &info) != 0)
{
perror("An error occurred. Write permissions maybe?!!");
return;
}
FILE* f = std::fopen(filename, "wb");
const char* text = "Some text I want to write...";
std::fwrite(text, 1, strlen(text), f);
std::fclose(f);
}
The funny thing is, it writes the first file successfully. For the second file, it passes the existence check and again, gets stuck at the last line. It doesn't even throw an exception! Just remains there doing nothing...
You can't use COM4.ini as a filename, see https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
Specifially
"CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces."
It attempts to open a serial port called COM4 instead...
I'm trying to open a file to treat it later. My problem is that if my file name is not ANSI (Arabic, Hindi...) fopen_s and fopen refuse to open it and give me an Invalid argument error. I can't use CreateFile() to do that so I thought to check either my file name is supported by fopen or not(try to open it) and create a temporary file instead:
QString fileN=QString::fromWCharArray(fname);
QFileInfo file(DIRPath+"/"+fileN);
bool Supported=true;
if(file.exists()) {
QString temp;
char* Fname=(char*)malloc(260*sizeof(char));
strcpy(Fname,(QString(DIRPath+"/"+fileN).toStdString()).c_str());
FILE* Filedesc;
errno_t err=fopen_s(&Filedesc,Fname,"rb");
if(Filedesc!=NULL) {
qDebug()<<"\nfile opened ";
fclose(Filedesc);
} else if(err==22) {
qDebug()<<"\nfail to open file error 22: Invalid argument";
temp=QString(DIRPath+"/Temp"+QString::number(nb));
Supported=false;
} else qDebug()<<"\nfail to open file error"<<GetLastError()<<"errno"<<errno<<"strerrno"<<strerror(errno);
Fname=NULL;
free(Fname);
...
My question is: can anyone clarify for me the UNICODE/ANSI confusion? Am I safe so far or are there more precautions to consider? Is there a safer way to check if the given name is not ANSI?
Thank you in advance, any help will be appreciated.
EDIT 1
I tried this but in vain : CreateFile() return an INVALID_HANDLE_VALUE and GetLastError() return 0
//WCHAR fname[]=L"D:/أحدالأنشطة.txt";
char* name="D:/أحدالأنشطة.txt";
wchar_t* nameW=(wchar_t*)malloc(sizeof(wchar_t)*17);
qDebug()<<"s :"<<mbstowcs(nameW,name,17);
//QString path=QString::fromWCharArray(fname,17);
//QString path=QString::fromLatin1(name,17);
HANDLE fileHandle = CreateFile( nameW, // file to open
GENERIC_READ, // open for reading
FILE_SHARE_READ, // share for reading
NULL, // default security
OPEN_EXISTING, // existing file only
FILE_ATTRIBUTE_NORMAL, // normal file
NULL);
if (fileHandle == INVALID_HANDLE_VALUE)
{
qDebug()<<"CreateFile failed!\n"<<GetLastError();
nameW=NULL;
free(nameW);
return 2;
}else
qDebug()<<"CreateFile succeeded!\n";
int fd = _open_osfhandle((intptr_t) fileHandle, _O_RDONLY);
FILE* fstr = _fdopen(fd, "r");
QFile indirect;
if (!indirect.open(fstr, QIODevice::ReadOnly))
qDebug()<<"QFile open against file descriptor failed!\n";
else
{
qDebug()<<"QFile open against file descriptor succeeded!\n";
indirect.close();
}
// This will fail
QFile direct(path);
if (!direct.open(QIODevice::ReadOnly))
qDebug()<<"QFile open of filename directly failed!\n";
else
{
qDebug()<<"QFile open of filename directly succeeded!\n";
direct.close();
}
nameW=NULL;
free(nameW);
EDIT 2
QString fname(QFile::decodeName("D:/أحدالأنشطة.txt"));
QFile qFile(fname);
bool b=qFile.open(QIODevice::ReadOnly);
if(b)
{
FILE* filedesc = fdopen(qFile.handle(), "rb");
if(filedesc!=NULL)
{
char* nb=(char*)malloc(2*sizeof(char));
qDebug()<<"opened ";
size_t size=fread(nb,sizeof(char),2,filedesc);
fclose(filedesc);
qDebug()<<"filedesc closed size "<<size<<"nb "<<QString::fromAscii(nb,2);
nb=NULL;
free(nb);
}else qDebug()<<"filedesc failed error"<<strerror(errno);
}else
qDebug()<<"qFile failed error"<<strerror(errno);
You should probably use QFile to open the file, and then pass QFile::handle() to your C function. In the C code you would then use fdopen() to associate a FILE* stream to the file descriptor. Note that the mode you use in fdopen() should be compatible with the mode you used in QFile::open(). For example:
void c_func(int fd)
{
FILE* file = fdopen(fd, "rb");
// ...
}