IVFSExplorer->entryList types array returns 1 (unknown) for all entries on certain file systems => special FS-related -> Fixed in SVN

[Ian Moore]

It appears that IVFSExplorer->entryList returns a 1 (unknown) type for all entries on certain file systems. This is the only conclusion I can come to.

Mount:

/dev/md0 on / type ext3 (rw,errors=remount-ro)
/dev/md1 on /SPACEHUB type xfs (rw,noatime,nobarrier,sunit=128,swidth=256)
/SPACEHUB on /exports/space type bind (rw,bind)
/SPACEHUB/www on /exports/www type bind (rw,bind)
/SPACEHUB/www/singularity on /var/www type bind (rw,bind)

Output from entryList call on /exports:

/exports/
Array
(
    [0] => space
    [1] => www
)
Array
(
    [0] => 4
    [1] => 4
)

Output from entryList call on /SPACEHUB/VirtualBox/

Array
(
    [0] => .bash_history
    [1] => .config
    [2] => .VirtualBox
    [3] => VirtualBox
    [4] => .ssh
... etc.. .
Array
(
    [0] => 1
    [1] => 1
    [2] => 1
    [3] => 1
    [4] => 1
...etc...

The same call on /exports/space (where /SPACEHUB is mounted 'bind') gives similar results. The same call to ANYTHING in /SPACEHUB gives similar results. I can only guess that the file system type is causing this. That really doesn't make any sense either because as far as I know, stat() is stat(). Assuming the API just calls stat. /SPACEHUB is world rx.

stat returns directory for both:

  File: `/exports'
  Size: 4096            Blocks: 8          IO Block: 4096   directory

  File: `/SPACEHUB/VirtualBox'
  Size: 4096            Blocks: 8          IO Block: 4096   directory

Browsing folders works correctly from the VirtualBox GUI, but that probably uses local access rather than going through IVFSExplorer. Again, I could be wrong, but the only thing I can think of is file system type.

There are no errors in the log file for vboxwebsrv or system logs. vboxwebsrv is probably just happily returning what it's getting over XPCOM.

[Ian Moore]

More info: Going through the source code, I think this comes down to XFS not supporting dirent::d_type. I think IVFSExplorer relies on a directory entry supporting this rather than running stat(). I believe there are other file systems out there that also do not support this.

Please excuse my limited knowledge of c++ and therefore possibly annoying suggestion, but I would like make the following suggestion: It looks like the function rtDirRemoveRecursiveSub in src/VBox/Runtime/r3/dir.cpp correctly handles these instances by using RTPathQueryInfoEx if d_type is unknown:

/* Deal with the unknown type. */
if (pDirEntry->enmType == RTDIRENTRYTYPE_UNKNOWN)
{
rc = RTPathQueryInfoEx(... etc...
...etc...

Could RTDirRead and RTDirReadEx in src/VBox/Runtime/r3/posix/dir-posix.cpp be changed to do this as well?

Thank you

[Ian Moore]

With all due respect, this is not just XFS related. The following file systems do not support d_type:

reiserfs, jfs, xfs, nfs

Confirmed with NFS. d_type is unknown until I do an 'ls' (which calls stat()) in the directory. I assume after that an entry's d_type is cached by the OS and returned. I understand that XFS isn't the most popular fs out there, but surely there are many people using NFS.

[Frank Mehnert]

Well, this title is just to get a rough idea where this problem comes from.

[Christian Pötzsch]

Fixed in the next major release.

[Frank Mehnert]

Fixed in VBox 4.0.