Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#240 closed defect (fixed)

File system view in QtCreator doesn't enter certain directories

Reported by: rudi Owned by:
Priority: major Milestone: Qt 4.next
Component: General Version:
Severity: low Keywords:
Cc:

Description

This is most likely a LIBC issue, but I'd like your comment on this. Creator uses the following code snippet:

   const QFileInfo fi = m_fileSystemModel->fileInfo(srcIndex);
   if (fi.isReadable() && fi.isExecutable())
       setCurrentDirectory(m_fileSystemModel->filePath(srcIndex));

For some strange reason, some directories on my (JFS) partition don't have any permission bits set (i.e. st_mode == S_IFDIR), which causes the above code not to work as expected.

Change History (6)

comment:1 Changed 3 years ago by rudi

I just found out that all directories showing this problem were created from the file dialog of a QT3 program. I don't know how QT3 manages this. All directories created from the command line or the WPS have permissions 0777. Note, that our current QT4 file dialog sets permissions of a freshly created dir to 0755 (i.e. no write privileges for group and world).

BTW, this happens JFS and HPFS, but not on FAT32 or a Novell network. On the latter even Qt-created dirs show 0777.

Last edited 3 years ago by rudi (previous) (diff)

comment:2 Changed 3 years ago by dmik

  • Milestone changed from Qt 4.7 to Qt 4.next

LIBC uses EAs for storing Unix permission bits. Since FAT32 and Novell don't have EAs, it uses some sane defaults for them.

Can you check the contents of EAs for those dirs? I can't recall anything special about Qt3 so far that could cause this (and I don't have the Qt3 sources ATM).

comment:3 Changed 3 years ago by rudi

Qt3 uses QT_MKDIR(), which is defined in qplatformdefs.h as ::mkdir(name, 0). This explains the zero permissions. In Qt4, ::mkdir() is called directly with permissions set to 0777. We still end up with 0755, but that that is probably controlled by umask(). BTW, our current qplatformdefs.h still contains the QT_MKDIR macro indentical to Qt3. Maybe we should change that...

BTW, both FAT32 as well as Novell do support EAs just fine. So this appears to be a bug in LIBC.

comment:4 Changed 3 years ago by dmik

I now recalled that LIBC has a hard coded list of systems that it thinks support EAs. See http://svn.netlabs.org/libc/ticket/21 and http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/lib/sys/fs.c#L1907.

BTW, while speaking of EAs, beware that there are problems with them on HPFS386 (see http://svn.netlabs.org/libc/ticket/230 and http://svn.netlabs.org/libc/ticket/231) and other unsupported systems may expose similar bugs as well.

comment:5 Changed 3 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

The QT_MKDIR problem was fixed in r1023.

comment:6 Changed 3 years ago by rudi

Are you sure that this fix is right ? I think LIBC's mkdir requires two arguments.

Nevermind. Didn't look close enough.

Last edited 3 years ago by rudi (previous) (diff)
Note: See TracTickets for help on using tickets.