Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#191 closed defect (fixed)

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

Reported by: rudi Owned by:
Priority: major Milestone: Qt 4.6.3
Component: QtGui Version: 4.6.2
Severity: low Keywords:
Cc:

Description

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.

Attachments (2)

remote_cdrom_not_ready.jpg (27.8 KB) - added by rudi 9 years ago.
Screenshot showing the issue
qfileiconprovider.diff (1.1 KB) - added by rudi 9 years ago.
Fix for the above problem

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by rudi

Screenshot showing the issue

Changed 9 years ago by rudi

Fix for the above problem

comment:1 Changed 9 years ago by dmik

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.

comment:2 Changed 9 years ago by dmik

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

comment:3 Changed 9 years ago by dmik

  • Milestone changed from Qt Enhanced to Qt 4.6.3
  • Resolution set to fixed
  • Status changed from new to closed

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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by 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;
	}
    }
}

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by rudi

Any comments ?

comment:9 Changed 9 years ago by dmik

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...

comment:10 Changed 9 years ago by 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.

comment:11 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.