VirtualBox

Ticket #7026 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

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

Reported by: imoore76 Owned by:
Priority: minor Component: webservices
Version: VirtualBox 3.2.4 Keywords: IVFSExplorer
Cc: Guest type: other
Host type: Linux

Description

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.

Change History

comment:1 Changed 4 years ago by imoore76

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

comment:2 Changed 4 years ago by frank

  • Summary changed from IVFSExplorer->entryList types array returns 1 (unknown) for all entries on certain file systems to IVFSExplorer->entryList types array returns 1 (unknown) for all entries on certain file systems => XFS-related

comment:3 Changed 4 years ago by imoore76

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.

comment:4 Changed 4 years ago by frank

  • Summary changed from IVFSExplorer->entryList types array returns 1 (unknown) for all entries on certain file systems => XFS-related to IVFSExplorer->entryList types array returns 1 (unknown) for all entries on certain file systems => special FS-related

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

comment:5 Changed 3 years ago by poetzsch

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

Fixed in the next major release.

comment:6 Changed 3 years ago by frank

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

Fixed in VBox 4.0.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use