Wrong icon shown in file dialog for "not ready" shared CD rom

[rudi]

Accessing a Windows 7 system using NetDrive?, the remote CD ROM drive gets assigned a Qt-default folder icon instead of a "native" one. This happens due to the fact, that WinLoadFileIcon? fails when there is no disk in the drive. Find patch attached. Please review.

[rudi]

Screenshot showing the issue

[rudi]

Fix for the above problem

[Dmitry A. Kuminov]

No disk in drive? How can WinLoadFileIcon?() know that a folder named "$X" corresponds to a CD-ROM drive? My guess is that NDFS returns a failure from DosQueryPathInfo?() for that directory and that's why WinLoadFileIcon?() fails.

[Dmitry A. Kuminov]

Also, I didn't quite get your comment "QPixmap::fromPmHPOINTER fails on "SysPointers?".

[Dmitry A. Kuminov]

In r825, I fixed the problem but a bit differently as this is a more general task (providing an icon for a non-existent path). See the comments in the changeset.

Thanks for reporting.

[rudi]

As for my comment: It looks like QPixmap::fromPmHPOINTER() works O.K. for icons returned by WinLoadFileIcon?(), but fails for those obtained by WinQuerySysPointer?(). I had preferred using the latter instead of loading the icon of a "known-to-exist" file or folder, but doing so is probably the easier solution.

[rudi]

Another note: I noticed that on some file systems there is an icon request for "X:" and "X:\..". This appears to happen on file systems, that expose a "." and a ".." entry in the root. When looking closer at this, it turned out that quit a few file systems (HPFS, JFS, NetDrive?) do behave this way. They set the attribute of these pseudo-dirs "hidden", but they return them on directory scans. Especially in case of NetDrive? this can contribute to the poor performance of the file dialog. Thus is suggest the we filter out these entries before the file dialog will see them.

[rudi]

Might try to add the following to qfsfileengine_iterator_os2.cpp right after line 250:

// skip (hidden) "." and ".." entries in root directories
if (path.size() == 3 && path.endsWith(QLatin1String(":/"))) {
    while( strcmp(that->platform->findBuf.achName, ".") == 0 ||
	   strcmp(that->platform->findBuf.achName, "..") == 0 ) {
	count = 1;
	if( DosFindNext(platform->hdir, &platform->findBuf,
		sizeof(platform->findBuf), &count) != NO_ERROR) {
	    that->platform->done = true;
	    break;
	}
    }
}

[rudi]

Scrap that one. Here's a version that doesn't potentially to leak dir handles in case of a completely empty drive...

// skip (hidden) "." and ".." entries in root directories
if (path.size() == 3 && path.endsWith(QLatin1String(":/"))) {
    while( !that->platform->done &&
           (strcmp(that->platform->findBuf.achName, ".") == 0 ||
            strcmp(that->platform->findBuf.achName, "..") == 0)) {
        that->advance();
    }
}

BTW, access to "X:\." and "X:\.." doesn't really contribute to the slowness of our file dialogs on NetDrive?. My suspicion was wrong in that case. However, IMHO it's still something we should avoid.

[rudi]

Any comments ?

[Dmitry A. Kuminov]

Okay, now I got your comment about the non-working QPixmap::fromPmHPOINTER(). But anyway, pointers returned by WinQuerySysPointer?() are not icons, they are mouse pointer shapes (intended for DnD, I suppose) and we don't want them to use as icons because they are black-and-white and just ugly. If we really need Qt icons from these pointers later, we will fix QPixmap::fromPmHPOINTER().

Regarding your ./.. proposal. These items are historically part of the root directory (this was so in DOS times and is still so in Windows AFAIR). I don't think we have a good reason to hide it from Qt completely ATM...

[rudi]

You are right WinQuerySysPointer?() does not return the icons I expected.

As for the other: Here is a quote from Microsoft's FAT document:

For FAT32, the root directory can be of variable size and is a cluster chain, 
just like any other directory is. The first cluster of the root directory on
a FAT32 volume is stored in BPB_RootClus. Unlike other directories, the root
directory itself on any FAT type does not have any date or time stamps, does
not have a file name (other than the implied file name “\”), and does not 
contain “.” and “..” files as the first two directory entries in the directory.

AFAIR, HPFS had a problem with that and it was IBMs dirty hack to hide them instead of making them invisible.

[rudi]

Oops, I should have written "instead of letting the file system not present them at all". BTW, my Windows (hey, just got a new machine here that builds Qt in VirtualBox? 3..4 times faster than my old one did) does not show them in the root either.