DSC_0094.JPG

- Yes, it is correct!

Capitals, 8 characters for a name and 3 characters for an extension. This format is used on your photo camera too, I believe.

Do you have any clue why it is so?

First of all. Do we want something else like 'MySuperPhotoShot_001.jpg'? Right now I don't have any idea when it could be needed/useful. Possibly you have a good one.

Let's go back to our question: why is the old DOS8.3 format of the file names used on the memory cards?

Here it comes. We have a flash memory as MMC, SD card or something of that sort. The FAT32 file system is a standard 'de facto' on the memory cards. Originally FAT file systems were designed to support the short file names known also as 8.3 filename. The file allocation table on FAT32 file system provides an information where the files are located on a disk. Each record of a file allocation table keeps a 8.3 filename and the file attributes, its size is 32 bits. Later in 1994 Microsoft introduced the long file name format in Windows NT 3.5. It is done in such a way that the file system with a new file name format could be easily read by a device that only understands DOS8.3 standard (backwards compatibility). Hm, logical. But don't forget the photo camera (on calendar the year is 2011) makes files in DOS8.3 format.

The new (? from 1994) long file name format is patented. Bingo! The software on a photo camera is not a Windows platform and therefore it could be a problem to use LFN format there.

End of story. Bye, bye. (c) Shrek.

More details about the file name format:
File Allocation Table  (especially chapter about a Microsoft patent).

First one!

It will be a first time I add the post here.

Create a framework is not an easy task.

Create a cross-platform application and UI framework is much more difficult one.

The framework that is used for more than 15 years and helped the hundreds of thousands of companies to deliver the services to the their clients is really something.

To find a mistake or a little thingy for improvement sometimes is not a big deal. Much easier to find something in someone's work than in your own.

Here is my finding in Qt framework version 4.6.3 and it applies to the latest 4.7.2 version of Qt.

qfsfileengine_win.cpp, line 1801:

bool QFSFileEngine::setSize(qint64 size)

{

    Q_D(QFSFileEngine);

    if (d->fileHandle != INVALID_HANDLE_VALUE || d->fd != -1) {

        // resize open file

        HANDLE fh = d->fileHandle;

#if !defined(Q_OS_WINCE)

        if (fh == INVALID_HANDLE_VALUE)

            fh = (HANDLE)_get_osfhandle(d->fd);

#endif

        if (fh == INVALID_HANDLE_VALUE)

            return false;

        qint64 currentPos = pos();

        if (seek(size) && SetEndOfFile(fh)) {

            seek(qMin(currentPos, size));

            return true;

        }

        seek(currentPos);

        return false;

    }

    if (!d->nativeFilePath.isEmpty()) {

        // resize file on disk

        QFile file(d->filePath);

        if (file.open(QFile::ReadWrite)) {

            bool ret = file.resize(size);

            if (!ret)

                setError(QFile::ResizeError, file.errorString());

            return ret;

        }

    }

    return false;

}

The almost everything is fine except one thing. Read the function from top to bottom and see what we have.

1. If the file is open (handle is not INVALID one) then set a new size of file.
2. If the file is NOT open then OPEN the file and set a new size.

Done?

Nope. The right way to close the file and then boil out. No one outside should care about stuff the function did for its own needs. The function opened the file to set a new size and leave the file handle opened. The current implementation (I believe) will close that kind of opened files in a destructor QFile::~QFile() and therefore there is no visible impact to the end users of that code.

Reading source code is a good habit.