VirtualBox

Opened 13 years ago

Last modified 3 years ago

#8761 assigned defect

Silent failure to delete files on Shared Folders

Reported by: Edmar (Macrovita) Owned by:
Component: shared folders Version: VirtualBox 4.0.6
Keywords: Cc:
Guest type: Linux Host type: Windows

Description (last modified by Frank Batschulat (Oracle))

When running bonnie++ bechmark on Linux guest (Fedora 14) in a shared folder under Windows XP host, the benchmark fails due to "directory not empty" at the end.

The benchmark creates thousands of small files, and then deletes them. The problem is that after all deletions are done (and no error is reported), the benchmark directory is not empty.

Running the same benchmark on the same guest, but on a Linux native folder (VDI disk), the benchmark runs OK. No files left over.

VirtualBox 4.0.6 (the problem also occurred on VirtualBox 4.0.4, I just hadn't reported it yet, sorry)
Host: Windows XP Professional SP3
Guest: Fedora 14 kernel 2.6.35.11-83.fc14.i686
bonnie++-1.96-1.fc13.i686

Terminal session:

# cd /media/sf_some_shared_folder
# bonnie++ -u root -n 3 -s 0
Using uid:0, gid:0.
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty
Cleaning up test directory after error.
# ls
Bonnie.1733
# ls Bonnie.1733/ | wc -l
1106
# for i in `seq 1 5`; do bonnie++ -u root -n 3 -s 0; done
Using uid:0, gid:0.
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Directory not empty
Cleaning up test directory after error.
...[snip, cut 4x repeated output]...
# for dir in `ls -d Bonnie*`; do \
    echo -n "files left over in $dir: "; \
    ls $dir | wc -l; done
files left over in Bonnie.1733: 1106
files left over in Bonnie.1743: 1111
files left over in Bonnie.1744: 1102
files left over in Bonnie.1745: 1102
files left over in Bonnie.1746: 1102
files left over in Bonnie.1747: 1108
# rm -rf Bonnie.*
# ls

Notes:

  • bonnie++ option [-n 3] creates 3 * 1024 files
  • The command [rm -rf Bonnie.*] successfully deletes all left over files. That said, as stated above the benchmark runs OK on native Linux guest disk instead of shared folder, so it seems the problem is not in bonnie++ code.
  • There's no error / no message appearing at VBox.log for the running VM right before, during or after the benchmark. See attached file VBox-20110421-1939.log.

BTM3505 (self reference, please ignore)

Attachments (1)

VBox-20110421-1939.log (91.5 KB ) - added by Edmar (Macrovita) 13 years ago.

Download all attachments as: .zip

Change History (26)

by Edmar (Macrovita), 13 years ago

Attachment: VBox-20110421-1939.log added

comment:1 by frankieandshadow, 12 years ago

I think I have what is probably the same problem in a different guise.

I am deleting (from a script) a folder on a SHARED DRIVE (host Windows 7, guest Debian) of some moderately large and many files in a tree three levels deep, with "rm -r path". It randomly gives errors 'rm: cannot remove '<intermediate directory>': Directory not empty' and because of that ultimately fails to delete the top level folder. I think it is trying to do the delete on the directory, but the recursive delete on the contents has not completed.

I think there is a similar situation that mv on a large-ish directory on a shared folder completes some time after the mv returns.

comment:2 by nickblah, 12 years ago

I believe I'm also seeing the same issue with a shared folder. OS X Lion Host, CentOS 6.2 guest, VirtualBox 4.1.16. Basically recursive deletes seem to fail if the directory has enough contents. Even though "rm" reports having deleted certain files, they still remain on the shared folder file system, so deleting the parent folder fails. Repeated recursive delete commands will eventually delete the whole folder, but that's not ideal and not very practical when using 3rd party tools that expect recursive deletes to work the first time.

Here's an example using PHP PEAR's Pyrus installer:

$ php pyrus.phar ./vendor/pear install pear/Auth
Pyrus version 2.0.0a4 SHA-1: 72271D92C3AA1FA96DF9606CD538868544609A52
Using PEAR installation found at /vagrant_sites/my_site/main/releases/main/vendor/pear
Downloading pear.php.net/Auth
Mime-type: application/octet-stream
Pyrus\AtomicFileTransaction\MultiException: Warning: not all backup directories have been removed====>] 100% (54/54 kb)
 Pyrus\IOException: Unable to fully remove /vagrant_sites/my_site/main/releases/main/vendor/pear/.old-php
  Pyrus\IOException: Unable to fully remove /vagrant_sites/my_site/main/releases/main/vendor/pear/.old-data
   Pyrus\IOException: Unable to fully remove /vagrant_sites/my_site/main/releases/main/vendor/pear/.old-docs
    Pyrus\IOException: Unable to fully remove /vagrant_sites/my_site/main/releases/main/vendor/pear/.old-tests

If I then manually delete the ".old-*" directories it's complaining about, the following happens:

$ rm -Rv vendor/pear/.old-*
removed `vendor/pear/.old-data/MDB2/LICENSE'
rm: cannot remove `vendor/pear/.old-data/MDB2': Directory not empty
removed `vendor/pear/.old-data/MDB2_Driver_oci8/package_oci8.xml'
rm: cannot remove `vendor/pear/.old-data/MDB2_Driver_oci8': Directory not empty
removed `vendor/pear/.old-data/PEAR/package.dtd'
removed `vendor/pear/.old-data/PEAR/template.spec'
rm: cannot remove `vendor/pear/.old-data/PEAR': Directory not empty
removed `vendor/pear/.old-data/Structures_Graph/LICENSE'
removed directory: `vendor/pear/.old-data/Structures_Graph'
removed `vendor/pear/.old-docs/Archive_Tar/docs/Archive_Tar.txt'
removed directory: `vendor/pear/.old-docs/Archive_Tar/docs'
rm: cannot remove `vendor/pear/.old-docs/Archive_Tar': Directory not empty
removed `vendor/pear/.old-docs/MDB2/docs/CONTRIBUTORS'
removed `vendor/pear/.old-docs/MDB2/docs/datatypes.html'
removed `vendor/pear/.old-docs/MDB2/docs/examples/example.php'
removed `vendor/pear/.old-docs/MDB2/docs/examples/example_php5.php'
removed `vendor/pear/.old-docs/MDB2/docs/examples/metapear_test_db.schema'
removed directory: `vendor/pear/.old-docs/MDB2/docs/examples'
removed `vendor/pear/.old-docs/MDB2/docs/MAINTAINERS'
removed `vendor/pear/.old-docs/MDB2/docs/README'
removed `vendor/pear/.old-docs/MDB2/docs/STATUS'
removed `vendor/pear/.old-docs/MDB2/docs/TODO'
removed directory: `vendor/pear/.old-docs/MDB2/docs'
rm: cannot remove `vendor/pear/.old-docs/MDB2': Directory not empty
removed `vendor/pear/.old-docs/PEAR/INSTALL'
removed `vendor/pear/.old-docs/PEAR/LICENSE'
removed `vendor/pear/.old-docs/PEAR/README'
rm: cannot remove `vendor/pear/.old-docs/PEAR': Directory not empty
removed `vendor/pear/.old-docs/Structures_Graph/docs/generate.sh'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/classtrees_Structures_Graph.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/elementindex.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/elementindex_Structures_Graph.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/errors.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/index.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/li_Structures_Graph.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/media/banner.css'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/media/stylesheet.css'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs/html/media'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/packages.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/_Structures_Graph_Manipulator_AcyclicTest_php.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/_Structures_Graph_Manipulator_TopologicalSorter_php.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/_Structures_Graph_Node_php.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/_Structures_Graph_php.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/Structures_Graph.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/Structures_Graph_Manipulator_AcyclicTest.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/Structures_Graph_Manipulator_TopologicalSorter.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/Structures_Graph_Node.html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph/tutorial_Structures_Graph.pkg.html'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs/html/Structures_Graph'
removed `vendor/pear/.old-docs/Structures_Graph/docs/html/todolist.html'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs/html'
removed `vendor/pear/.old-docs/Structures_Graph/docs/tutorials/Structures_Graph/Structures_Graph.pkg'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs/tutorials/Structures_Graph'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs/tutorials'
removed directory: `vendor/pear/.old-docs/Structures_Graph/docs'
rm: cannot remove `vendor/pear/.old-docs/Structures_Graph': Directory not empty
removed `vendor/pear/.old-docs/XML_Util/XML/examples/example.php'
removed `vendor/pear/.old-docs/XML_Util/XML/examples/example2.php'
removed directory: `vendor/pear/.old-docs/XML_Util/XML/examples'
removed directory: `vendor/pear/.old-docs/XML_Util/XML'
removed directory: `vendor/pear/.old-docs/XML_Util'
removed `vendor/pear/.old-php/Archive/Tar.php'
rm: cannot remove `vendor/pear/.old-php/Archive': Directory not empty
removed `vendor/pear/.old-php/Console/Getopt.php'
rm: cannot remove `vendor/pear/.old-php/Console': Directory not empty
removed `vendor/pear/.old-php/MDB2/Date.php'
removed `vendor/pear/.old-php/MDB2/Driver/Datatype/Common.php'
removed `vendor/pear/.old-php/MDB2/Driver/Datatype/oci8.php'
removed directory: `vendor/pear/.old-php/MDB2/Driver/Datatype'
removed `vendor/pear/.old-php/MDB2/Driver/Function/Common.php'
removed `vendor/pear/.old-php/MDB2/Driver/Function/oci8.php'
removed directory: `vendor/pear/.old-php/MDB2/Driver/Function'
removed `vendor/pear/.old-php/MDB2/Driver/Manager/Common.php'
removed `vendor/pear/.old-php/MDB2/Driver/Manager/oci8.php'
removed directory: `vendor/pear/.old-php/MDB2/Driver/Manager'
removed `vendor/pear/.old-php/MDB2/Driver/Native/Common.php'
removed `vendor/pear/.old-php/MDB2/Driver/Native/oci8.php'
removed directory: `vendor/pear/.old-php/MDB2/Driver/Native'
removed `vendor/pear/.old-php/MDB2/Driver/oci8.php'
removed `vendor/pear/.old-php/MDB2/Driver/Reverse/Common.php'
removed `vendor/pear/.old-php/MDB2/Driver/Reverse/oci8.php'
removed directory: `vendor/pear/.old-php/MDB2/Driver/Reverse'
removed directory: `vendor/pear/.old-php/MDB2/Driver'
removed `vendor/pear/.old-php/MDB2/Extended.php'
removed `vendor/pear/.old-php/MDB2/Iterator.php'
removed `vendor/pear/.old-php/MDB2/LOB.php'
rm: cannot remove `vendor/pear/.old-php/MDB2': Directory not empty
removed `vendor/pear/.old-php/MDB2.php'
removed `vendor/pear/.old-php/OS/Guess.php'
rm: cannot remove `vendor/pear/.old-php/OS': Directory not empty
removed `vendor/pear/.old-php/PEAR/Autoloader.php'
removed `vendor/pear/.old-php/PEAR/Builder.php'
removed `vendor/pear/.old-php/PEAR/ChannelFile/Parser.php'
removed directory: `vendor/pear/.old-php/PEAR/ChannelFile'
removed `vendor/pear/.old-php/PEAR/ChannelFile.php'
removed `vendor/pear/.old-php/PEAR/Command/Auth.php'
removed `vendor/pear/.old-php/PEAR/Command/Auth.xml'
removed `vendor/pear/.old-php/PEAR/Command/Build.php'
removed `vendor/pear/.old-php/PEAR/Command/Build.xml'
removed `vendor/pear/.old-php/PEAR/Command/Channels.php'
removed `vendor/pear/.old-php/PEAR/Command/Channels.xml'
removed `vendor/pear/.old-php/PEAR/Command/Common.php'
removed `vendor/pear/.old-php/PEAR/Command/Config.php'
removed `vendor/pear/.old-php/PEAR/Command/Config.xml'
removed `vendor/pear/.old-php/PEAR/Command/Install.php'
removed `vendor/pear/.old-php/PEAR/Command/Install.xml'
removed `vendor/pear/.old-php/PEAR/Command/Mirror.php'
removed `vendor/pear/.old-php/PEAR/Command/Mirror.xml'
removed `vendor/pear/.old-php/PEAR/Command/Package.php'
removed `vendor/pear/.old-php/PEAR/Command/Package.xml'
removed `vendor/pear/.old-php/PEAR/Command/Pickle.php'
removed `vendor/pear/.old-php/PEAR/Command/Pickle.xml'
removed `vendor/pear/.old-php/PEAR/Command/Registry.php'
removed `vendor/pear/.old-php/PEAR/Command/Registry.xml'
removed `vendor/pear/.old-php/PEAR/Command/Remote.php'
removed `vendor/pear/.old-php/PEAR/Command/Remote.xml'
removed `vendor/pear/.old-php/PEAR/Command/Test.php'
removed `vendor/pear/.old-php/PEAR/Command/Test.xml'
removed directory: `vendor/pear/.old-php/PEAR/Command'
removed `vendor/pear/.old-php/PEAR/Command.php'
removed `vendor/pear/.old-php/PEAR/Common.php'
removed `vendor/pear/.old-php/PEAR/Config.php'
removed `vendor/pear/.old-php/PEAR/Dependency2.php'
removed `vendor/pear/.old-php/PEAR/DependencyDB.php'
removed `vendor/pear/.old-php/PEAR/Downloader/Package.php'
removed directory: `vendor/pear/.old-php/PEAR/Downloader'
removed `vendor/pear/.old-php/PEAR/Downloader.php'
removed `vendor/pear/.old-php/PEAR/ErrorStack.php'
removed `vendor/pear/.old-php/PEAR/Exception.php'
removed `vendor/pear/.old-php/PEAR/FixPHP5PEARWarnings.php'
removed `vendor/pear/.old-php/PEAR/Frontend/CLI.php'
removed directory: `vendor/pear/.old-php/PEAR/Frontend'
removed `vendor/pear/.old-php/PEAR/Frontend.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Cfg.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Cfg.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Common.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Data.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Data.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Doc.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Doc.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Ext.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Ext.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Php.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Php.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Script.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Script.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Src.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Src.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Test.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Test.xml'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Www.php'
removed `vendor/pear/.old-php/PEAR/Installer/Role/Www.xml'
removed directory: `vendor/pear/.old-php/PEAR/Installer/Role'
removed `vendor/pear/.old-php/PEAR/Installer/Role.php'
removed directory: `vendor/pear/.old-php/PEAR/Installer'
removed `vendor/pear/.old-php/PEAR/Installer.php'
removed `vendor/pear/.old-php/PEAR/PackageFile/Generator/v1.php'
removed `vendor/pear/.old-php/PEAR/PackageFile/Generator/v2.php'
removed directory: `vendor/pear/.old-php/PEAR/PackageFile/Generator'
removed `vendor/pear/.old-php/PEAR/PackageFile/Parser/v1.php'
removed `vendor/pear/.old-php/PEAR/PackageFile/Parser/v2.php'
removed directory: `vendor/pear/.old-php/PEAR/PackageFile/Parser'
removed `vendor/pear/.old-php/PEAR/PackageFile/v1.php'
removed `vendor/pear/.old-php/PEAR/PackageFile/v2/rw.php'
removed `vendor/pear/.old-php/PEAR/PackageFile/v2/Validator.php'
removed directory: `vendor/pear/.old-php/PEAR/PackageFile/v2'
removed `vendor/pear/.old-php/PEAR/PackageFile/v2.php'
removed directory: `vendor/pear/.old-php/PEAR/PackageFile'
removed `vendor/pear/.old-php/PEAR/PackageFile.php'
removed `vendor/pear/.old-php/PEAR/Packager.php'
removed `vendor/pear/.old-php/PEAR/Registry.php'
removed `vendor/pear/.old-php/PEAR/REST/10.php'
removed `vendor/pear/.old-php/PEAR/REST/11.php'
removed `vendor/pear/.old-php/PEAR/REST/13.php'
removed directory: `vendor/pear/.old-php/PEAR/REST'
removed `vendor/pear/.old-php/PEAR/REST.php'
removed `vendor/pear/.old-php/PEAR/RunTest.php'
removed `vendor/pear/.old-php/PEAR/Task/Common.php'
removed `vendor/pear/.old-php/PEAR/Task/Postinstallscript/rw.php'
removed directory: `vendor/pear/.old-php/PEAR/Task/Postinstallscript'
removed `vendor/pear/.old-php/PEAR/Task/Postinstallscript.php'
removed `vendor/pear/.old-php/PEAR/Task/Replace/rw.php'
removed directory: `vendor/pear/.old-php/PEAR/Task/Replace'
removed `vendor/pear/.old-php/PEAR/Task/Replace.php'
removed `vendor/pear/.old-php/PEAR/Task/Unixeol/rw.php'
removed directory: `vendor/pear/.old-php/PEAR/Task/Unixeol'
removed `vendor/pear/.old-php/PEAR/Task/Unixeol.php'
removed `vendor/pear/.old-php/PEAR/Task/Windowseol/rw.php'
removed directory: `vendor/pear/.old-php/PEAR/Task/Windowseol'
removed `vendor/pear/.old-php/PEAR/Task/Windowseol.php'
removed directory: `vendor/pear/.old-php/PEAR/Task'
removed `vendor/pear/.old-php/PEAR/Validate.php'
removed `vendor/pear/.old-php/PEAR/Validator/PECL.php'
removed directory: `vendor/pear/.old-php/PEAR/Validator'
removed `vendor/pear/.old-php/PEAR/XMLParser.php'
rm: cannot remove `vendor/pear/.old-php/PEAR': Directory not empty
removed `vendor/pear/.old-php/PEAR.php'
removed `vendor/pear/.old-php/PEAR5.php'
removed `vendor/pear/.old-php/pearcmd.php'
removed `vendor/pear/.old-php/peclcmd.php'
removed `vendor/pear/.old-php/Structures/Graph/Manipulator/AcyclicTest.php'
removed `vendor/pear/.old-php/Structures/Graph/Manipulator/TopologicalSorter.php'
removed directory: `vendor/pear/.old-php/Structures/Graph/Manipulator'
removed `vendor/pear/.old-php/Structures/Graph/Node.php'
removed directory: `vendor/pear/.old-php/Structures/Graph'
removed `vendor/pear/.old-php/Structures/Graph.php'
rm: cannot remove `vendor/pear/.old-php/Structures': Directory not empty
removed `vendor/pear/.old-php/System.php'
removed `vendor/pear/.old-php/XML/Util.php'
removed directory: `vendor/pear/.old-php/XML'
removed `vendor/pear/.old-tests/MDB2/tests/basic.phpt'
removed `vendor/pear/.old-tests/MDB2/tests/clitest.php'
removed `vendor/pear/.old-tests/MDB2/tests/config.php'
removed `vendor/pear/.old-tests/MDB2/tests/Console_TestListener.php'
removed `vendor/pear/.old-tests/MDB2/tests/driver_test.schema.xml'
removed `vendor/pear/.old-tests/MDB2/tests/HTML_TestListener.php'
removed `vendor/pear/.old-tests/MDB2/tests/import.schema.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_api_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_bugs_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_Connect_Test.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_datatype_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_extended_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_function_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_internals_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_manager_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_native_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_ibase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_mssql.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_mysql.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_mysqli.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_oci8.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_pgsql.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_nonstandard_sqlite.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_reverse_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/MDB2_usage_testcase.php'
removed `vendor/pear/.old-tests/MDB2/tests/README'
removed `vendor/pear/.old-tests/MDB2/tests/test.php'
removed `vendor/pear/.old-tests/MDB2/tests/test_setup.php.dist'
removed `vendor/pear/.old-tests/MDB2/tests/testchoose.php'
removed `vendor/pear/.old-tests/MDB2/tests/tests.css'
removed `vendor/pear/.old-tests/MDB2/tests/testUtils.php'
removed directory: `vendor/pear/.old-tests/MDB2/tests'
rm: cannot remove `vendor/pear/.old-tests/MDB2': Directory not empty
removed `vendor/pear/.old-tests/MDB2_Driver_oci8/tests/MDB2_nonstandard_oci8.php'
removed directory: `vendor/pear/.old-tests/MDB2_Driver_oci8/tests'
rm: cannot remove `vendor/pear/.old-tests/MDB2_Driver_oci8': Directory not empty
removed `vendor/pear/.old-tests/Structures_Graph/tests/AllTests.php'
removed `vendor/pear/.old-tests/Structures_Graph/tests/testCase/BasicGraph.php'
removed directory: `vendor/pear/.old-tests/Structures_Graph/tests/testCase'
removed directory: `vendor/pear/.old-tests/Structures_Graph/tests'
rm: cannot remove `vendor/pear/.old-tests/Structures_Graph': Directory not empty
removed `vendor/pear/.old-tests/XML_Util/XML/tests/AllTests.php'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_apiVersion.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_attributesToString.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_collapseEmptyTags.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createCDataSection.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createComment.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createEndElement.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createStartElement.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createTag.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_createTagFromArray.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_getDocTypeDeclaration.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_getXmlDeclaration.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_isValidName.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_raiseError.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_replaceEntities.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_reverseEntities.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBasic_splitQualifiedName.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBug_4950.phpt'
removed `vendor/pear/.old-tests/XML_Util/XML/tests/testBug_5392.phpt'
removed directory: `vendor/pear/.old-tests/XML_Util/XML/tests'
removed directory: `vendor/pear/.old-tests/XML_Util/XML'
removed directory: `vendor/pear/.old-tests/XML_Util'

As an example of a failed delete, note in that output these lines:

removed `vendor/pear/.old-tests/MDB2_Driver_oci8/tests/MDB2_nonstandard_oci8.php'
removed directory: `vendor/pear/.old-tests/MDB2_Driver_oci8/tests'
rm: cannot remove `vendor/pear/.old-tests/MDB2_Driver_oci8': Directory not empty

But if I check that directory, MDB2_nonstandard_oci8.php and the tests directory still remain on disk, despite rm thinkinging it had successfully deleted them:

$ ls -l vendor/pear/.old-tests/MDB2_Driver_oci8/
total 0
drwxrwxrwx. 1 vagrant vagrant 102 Jun  2 09:32 tests
[vagrant@my_site main]$ ls -l vendor/pear/.old-tests/MDB2_Driver_oci8/tests/
total 8
-rwxrwxrwx. 1 vagrant vagrant 4457 Jun  2 09:32 MDB2_nonstandard_oci8.php

Using the force -f parameter on rm doesn't seem to make any difference. But like I said, after running the recursive delete command 1 or 2 more times all the files and folder will eventually get deleted and it will succeed.

Last edited 12 years ago by nickblah (previous) (diff)

comment:3 by pixeltreiber, 11 years ago

I have the same Problem here when deleting the cache of a Symfony2 Application. I use a shared folder and try to delete the cache in the guest. Host: Windows 7 Professional 64Bit

Guest: CentOS 6.3 Linux devel.local 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Virtualbox Version 4.2.6 r82870

comment:4 by snance, 11 years ago

I'm having the same issue, specifically using Symfony2's cache:clear (php).

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:        12.04
Codename:       precise

# ls /opt/
VBoxGuestAdditions-4.2.8

# app/console cache:clear
Clearing the cache for the dev environment with debug true

  [ErrorException]
  Warning: rmdir(/home/repx/www/app/cache/dev_old/jms_security): Directory not empty in /home/repx/www/vendor/symfony/symfony
  /src/Symfony/Component/Filesystem/Filesystem.php line 133

comment:5 by gregory.0xf0, 10 years ago

I'm seeing this same problem under Linux, specifically: Ubuntu 13.04 x86_64.

Guest: CentOS 4.8 (output of uname -a: Linux localhost.localdomain 2.6.9-89.EL #1 Mon Jun 22 12:19:40 EDT 2009 i686 i686 i386 GNU/Linux)

Virtualbox version: 4.2.10_Ubuntur84101

This can be easily reproduced in a shared folder (here in /share) by running the following:

$ mkdir -p /share/blah
$ touch /share/blah/{1..169}
$ rm -rf /share/blah  
rm: cannot remove directory `/share/blah': Directory not empty
$ ls -ln /share/blah                                                          
total 0
-rw-rw-r--  1 500 501 0 Jan  6 18:04 113

I can consistently reproduce this when attempting to delete the folder with >=169 items and it appear to never happen with <169 items. The file left is always "113" when 169 items are created.

Running mkdir -p /share/blah && touch /share/blah/{1..169} && strace rm -rf /share/blah contains an unlink() call for every file except 113. It looks like some unlink calls are being dropped when working with shared folders that contain larger than 168 entries for some reason...

Last edited 10 years ago by gregory.0xf0 (previous) (diff)

comment:6 by kburtch, 10 years ago

Problem still exists in VirtualBox 4.3.4.

Host is Solaris 11.1 on an Oracle X3-2 (SUN FIRE X4170 M3).

Client is Red Hat Enterprise Linux Server release 6.4 (Santiago).

[kburtch@testbox ~]$ bonnie++ -d /media/sf_hostshare/
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...Bonnie: drastic I/O error (rmdir): File exists
Cleaning up test directory after error.

This is repeatable (I've yet to get bonnie++ to complete when writing to the shared folder).

comment:7 by Moulino, 9 years ago

Problem still exists in VirtualBox 4.3.18.

Host is Windows 7 64 bits - Client is Debian 3.2.57-3 x86_64

rm -rf  /var/www/test/app/cache/dev_old/doctrine
rm: cannot remove `/var/www/test/app/cache/dev_old/doctrine': Directory not empty

comment:8 by anyqax, 8 years ago

Still exists in Version 5.0.14 r105127. Host Microsoft Windows 8.1 Pro [6.3.9600] Guest Linux 3.13.0-77-generic #121-Ubuntu

php app/console cache:clear
Clearing the cache for the dev environment with debug true

[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove directory "/vagrant/root/app/cache/dev_old/doctrine".

comment:9 by Marijn, 8 years ago

We have the same problem with a Debian 8x64 client and a ubuntu 14.04-x64 one. It occurs with a Windows 10 host, but also with a Mac OSX host.

The problem does NOT occur with a Debian 7x64 client. Maybe someone knows a workaround? It is a major problem for us.

> php app/console cache:clear --env=prod
Clearing the cache for the prod environment with debug false


[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove directory "/vagrant/app/cache/pro~/locking".

comment:10 by Salnikov, 8 years ago

Still exists in Version 5.0.14 r105127 MacOS + VirtualBox (CentOS7)

comment:11 by Marijn, 6 years ago

The problem still exists in VirtualBox 5.2.8. Seems to be the same as #15149 and #15897

comment:12 by virtuoze, 5 years ago

Still in ubuntu packages Ubuntu 18.04.1 LTS: Version 5.2.18_Ubuntu

comment:13 by binary1230, 5 years ago

Just hit this bug with:

guest: Ubuntu 18.04.1 LTS w/guest additions

host: Windows 10

Virtualbox version: 5.2.28 r 130011 (was also happening on 5.2.22)

shared folder type: vboxfs

I documented our efforts here: https://github.com/magfest/reggie-formula/issues/16

We were experiencing the same error with our python 'pip' installation. It had made a temp dir and tried to remove it, and even though according to the linux guest all the files were deleted, linux wouldn't remove the directory.

The broken dir buggy behavior could be repro'd like this:

(env) vagrant@localhost:~/dir$ rm -rf subdir/
rm: cannot remove 'subdir': Directory not empty
(env) vagrant@localhost:~/dir$ ls -alltr subdir/
drwxrwxrwx 1 vagrant vagrant 4096 Apr 27  2019 ..
drwxrwxrwx 1 vagrant vagrant 4096 Apr 27  2019 .

The folks at the meteor community hit this as well: https://github.com/meteor/meteor/issues/1337

On that thread, user 'glasser' came up with a very simple repro script:

#!/bin/bash

set -e -x

rm -rf a0 a1 a2
mkdir -p a0/subdir a1/subdir
echo HI >a0/subdir/file
echo HI >a1/subdir/file
mv a1 a2
mv a0 a1
rm a1/subdir/file
cat a2/subdir/file

expected result: prints 'HI'

actual result on vboxfs: 'cat: a2/subdir/file: No such file or directory'

This seems to happen when an application (like an installer) is modifying a lot of files very quickly, so perhaps this is some kind of race condition?

Regardless this is a really nasty bug. Any updates on any kind of fix, or status on what the technical limitations of getting it fixed are? Thanks!

Last edited 5 years ago by binary1230 (previous) (diff)

comment:14 by binary1230, 5 years ago

I'm working on a more slimmed down repro using as few syscalls as possible. That's now up here: https://github.com/binary1230/virtualbox-bug-7861-repro

That uses vagrant+virtualbox+vboxfs to setup a VM that demonstrates the bug. It should make getting to the bottom of this a lot easier hopefully.

the rename() syscall is where everything starts to go bad and probably where we need to dig in.

If I have time I will try and debug virtualbox/vboxfs myself if this is an easy fix, or provide more info.

comment:15 by binary1230, 4 years ago

I have some better repro code, and a hint about where this might be going wrong (currently have a kernel debug environment going and looking at this).

The short version is:

After running the repro code, it creates two directories on the guest which: Expected: these two directories should be independent from each other Actual: the two directories erroneously act like hard links (i.e. when you make a change in one dir)

On the HOST os, the directories are independent. On the GUEST, they are linked.

Curiously, clearing the kernel's inode+dentry cache with this command clears up the issue: echo 2 > /proc/sys/vm/drop_caches

I'm not really a kernel developer but it seems like this bug has something to do with the linux kernel serving up buggy data from the inode or dentry cache. Perhaps something to do with the lookup_hash functions in the vboxsf module.

I'm about to verify if this still happens with latest (6.1.8) virtualbox

I'll keep going. Anyone @Oracle, got any hints?

comment:16 by binary1230, 4 years ago

A more concise repro for this is:

(will upload the C code for this in a bit)

# run this to set it up. do it in a vboxfs mounted directory
rm -rf a0 a1 a2   # cleanup previous run
mkdir -p a0/subdir a1/subdir    # setup the directories

# we're setup. run this C code to trigger the bug
rename("a1", "a2");
rename("a0", "a1");

# --------------------
# bug is triggered
# --------------------

# now, after this is run, the a1/subdir and a2/subdir are erroneously 'hard linked'
echo "should only be in a1" > a1/subdir/file.txt
cat a2/subdir/file.txt   # THIS FILE SHOULDN'T EXIST, BUT IT DOES.

# one method to fix, clear the inode dentry cache
echo 2 > /proc/sys/vm/drop_caches

# now the error condition is fixed, and this command from before does what we expect (shows an error)
cat a2/subdir/file.txt  # should give you an error

comment:17 by binary1230, 4 years ago

just confirmed after compiling, this is still bugged in 6.1.8

comment:19 by Frank Batschulat (Oracle), 4 years ago

Owner: set to Frank Batschulat (Oracle)
Status: newaccepted

comment:20 by Frank Batschulat (Oracle), 4 years ago

Description: modified (diff)

see also:

#18776 Vagrant shared folders unable to install Package Management Plugins (Composer, PHP)
#19086 rm / rmdir not working correctly in shared folders

comment:21 by binary1230, 4 years ago

@fbatschu are you at Oracle, and were you looking into this?

If so I might have some more recent notes to upload about some kernel debugging I did before my entire setup decided it did not want to work anymore, and I have to rebuild the debugging environment from scratch again.

Let me know if I can be of any assistance, would be happy to get on a call or screen share or whatever. What started as seemingly a minor and mostly harmless inconvenience in one of our build scripts for our web application has turned into this pretty epic rabbit hole and I'm interested in seeing the fix through.

in reply to:  21 comment:22 by Frank Batschulat (Oracle), 4 years ago

Replying to binary1230:

If so I might have some more recent notes to upload about some kernel debugging I did before my entire setup decided it did not


Yes any debugging or information you have available and you think is valuable in solving the bug should be attached. Thanks!

comment:23 by Frank Batschulat (Oracle), 3 years ago

Owner: Frank Batschulat (Oracle) removed
Status: acceptedassigned

comment:24 by binary1230, 3 years ago

oh hey, I revisit this bug once per year, it's becoming a tradition :) @fbatschu if you fix it, the world will celebrate.


here's the starting point: https://github.com/binary1230/virtualbox-bug-7861-repro/tree/master

that uses Vagrant to set it all up, but, you don't actually need to use Vagrant if you have this setup another way.


there's a bunch of ways to trigger this bug, it seems like it really boils down to the rename() syscall malfunctioning when you are renaming a directory on vboxfs. something goes wrong and the filesystem starts returning weird results.

This C code reproduces and tests for the bad behavior in as few kernel syscalls as I could manage: https://github.com/binary1230/virtualbox-bug-7861-repro/blob/master/bug-demo.c

I highly recommend starting there.

I -think- a key thing here and maybe the most important hint is: This seems to be a problem with the state of the 'dentry' cache in linux (probably in the vboxfs kernel module)

The reason I think that? If you manually force the linux kernel to drop the cache, it fixes the broken behavior.

So, a simplified repro is:

#!/bin/bash

# setup the test
mkdir -p a0/subdir a1/subdir
echo HI >a0/subdir/file.txt
echo HI >a1/subdir/file.txt

# trigger the filesystem bugginess. 'mv' command calls the rename() syscall in the linux kernel
mv a1 a2     # ---> C code version: rename("a1", "a2");
mv a0 a1     # ---> C code version: rename("a0", "a1");

# demonstrate our directory access is now buggy. 
# removing one file here causes another one to be removed in an unrelated directory
# this behaves exactly like a 'hard link' would.
rm a1/subdir/file.txt

# EXPECTED: this file should still exist. 
# ACTUAL (INCORRECT): OS says this file is gone.
cat a2/subdir/file.txt

Here's the simplest way to clear the buggy behavior (it's not permanent and goes away when you restart or do other things, meaning, it's likely an issue with the kernel's in-memory cache)

# PART 2 ----> Clear the bugginess by manually clearing the 'dentry' (directory entry) cache
# (further reading about this command here: https://unix.stackexchange.com/questions/17936/setting-proc-sys-vm-drop-caches-to-clear-cache)
echo 2 > /proc/sys/vm/drop_caches

# run the same exact command as above 
# EXPECTED and ACTUAL: NOW it can't find the file (which is the correct behavior)
cat a2/subdir/file.txt

I will paste some more notes in another comment on my kernel debugging adventures looking into this

comment:25 by binary1230, 3 years ago

here are some other hints, this is going to be a bit of a mess, sorry. I hope it can be breadcrumbs for others who might choose to go down this rabbit hole. I compiled a debug linux kernel and was able to use GDB running on a windows host to debug a linux kernel inside a Virtualbox VM via a virtual serial port exposed as a named pipe in windows.


notes: EXTREMELY IMPORTANT: this bug only happens IFF both dirs are named "subdir".  if they are different, the behavior isn't triggered (some kind of hashing bug related to the same name?)

in GDB while debugging the kernel, here are some commands to try:

tell GDB to break in the vfs_mkdir() whenever the directories "subdir", "a0", or "a1" are being created from the repro steps. the idea here is to see if there's anything being setup incorrectly in the vboxfs implementations under this.

break vfs_mkdir if $_streq(dentry->d_name.name, "subdir") || $_streq(dentry->d_name.name, "a0") || $_streq(dentry->d_name.name, "a1")

I have a hunch that if we dig down more, something in inode_hashtable is incorrect and it's causing this bug. Some info on that datastructure here: https://www.google.com/books/edition/Understanding_the_Linux_Kernel/h0lltXyJ8aIC?hl=en&gbpv=1&bsq=inode_hashtable&pg=PT485&printsec=frontcover

It's this line in the linux code that creates the inode_hashtable: https://github.com/torvalds/linux/blob/5ceabb6078b80a8544ba86d6ee523ad755ae6d5e/fs/inode.c#L2103


Here's another interesting hint: the inode numbers (I think? I'm not sure) are out of wack in the test case.

CORRECT: expected behavior on non-vboxfs filesystem:

# set up 2 dirs and note the inode numbers: (#78523 and #80307)
mkdir -p a0/subdir a1/subdir
ls a0/subdir a1/subdir -dalli
### 78523 drwxrwxr-x 2 dom dom 4096 Apr 15 17:26 a0/subdir
### 80307 drwxrwxr-x 2 dom dom 4096 Apr 15 17:26 a1/subdir
### ^^^^^ <---- the inode#

# run rename() on a non-vboxfs filesystem
mv a1 a2
mv a0 a1

# we expect the inode#s to be the same after the rename, and indeed they are:
ls a1/subdir a2/subdir -dalli
### 78523 drwxrwxr-x 2 dom dom 4096 Apr 15 17:26 a1/subdir
### 80307 drwxrwxr-x 2 dom dom 4096 Apr 15 17:26 a2/subdir
### ^^^^^ <---- the inode#

Here's the same thing, but on vboxfs. I'm not sure if these are expected to not change, but, there's definitely something wacky going on here because dropping the cache causes them to change.

# this is after the buggy rename:
# setup our original directories: note: there are 2 different inode#s (#85 and #68)
ls a1/subdir a2/subdir -dalli
### 85 drwxrwxrwx 1 root root 0 May 19 01:16 a1/subdir
### 68 drwxrwxrwx 1 root root 0 May 19 01:16 a2/subdir
### ^^ <---- the inode#

# drop the cache, fixing the bug:
echo 2 > /proc/sys/vm/drop_caches

# BUG: THEY HAVE DIFFERENT INODE#'s!! is that expected with vboxfs? or is this broken? seems busted?
# if you do this on a normal non-vboxfs filesystem, this behavior doesn't happen.
ls a1/subdir a2/subdir -dalli
### 89 drwxrwxrwx 1 root root 0 May 19 01:16 a1/subdir
### 91 drwxrwxrwx 1 root root 0 May 19 01:12 a2/subdir
### ^^ <---- the inode#. THEY SHOULDN'T HAVE CHANGED? (I think? pretty sure)

I was trying (and didn't get far enough) to craft a syscall that could do a path lookup and IGNORE the cache, to see if it would return the correct behavior. then look at the two paths and see what was different.

this call would do it: path_openat(&nd, op, flags | LOOKUP_REVAL); the LOOKUP_REVAL flag means 'ignore dentry cache' https://lwn.net/Articles/649115/


some more ideas to chase:

// rename function in VFS
vfs_rename();

// lookup dentry from cache
struct dentry *__d_lookup(const struct dentry *parent, const struct qstr *name)

// where the dentry cache is originally allocated:
ffffffff821316e0 d dentry_cache
fs/dcache.c
struct dentry *__d_alloc(struct super_block *sb, const struct qstr *nam....
print inode_cachep

// show allocated slabs (of which the inode_cache is one of these)
sudo cat /proc/slabinfo | grep inode_cache

// lookup dentry in cache:
https://github.com/analogdevicesinc/linux/blob/master/fs/namei.c#L1520
static struct dentry *__lookup_hash(const struct qstr *name,
		struct dentry *base, unsigned int flags)


// I was trying to get a command that could dump the dentry cache, 
// I never found one but, this function looked promising?
// https://lkml.org/lkml/2017/8/3/891
take_dentry_name_snapshot()

here's a stack trace of the rename() syscall in the repro steps doing a lookup in the cache.

in vboxfs, the function sf_lookup() is where this eventually gets to.

first rename hitting the cache:
Thread 121 hit Breakpoint 1, sf_lookup (parent=0xffff888197278980, dentry=0xffff8881977689c0, flags=2048)
    at /root/VirtualBox-5.2.28/out/linux.amd64/debug/bin/additions/src/vboxsf/dirops.c:368
368     {
(gdb) bt
#0  sf_lookup (parent=0xffff888197278980, dentry=0xffff8881977689c0, flags=2048)
    at /root/VirtualBox-5.2.28/out/linux.amd64/debug/bin/additions/src/vboxsf/dirops.c:368
#1  0xffffffff8127b001 in __lookup_hash (name=0xffffc900010ebee8, base=0xffff888177c20f00, flags=2048)
    at fs/namei.c:1547
#2  0xffffffff81281a39 in do_renameat2 (olddfd=-100, oldname=<optimized out>, newdfd=<optimized out>,
    newname=<optimized out>, flags=<optimized out>) at fs/namei.c:4589
#3  0xffffffff81281d5c in __do_sys_rename (newname=<optimized out>, oldname=<optimized out>) at fs/namei.c:4675
#4  __se_sys_rename (newname=<optimized out>, oldname=<optimized out>) at fs/namei.c:4673
#5  __x64_sys_rename (regs=<optimized out>) at fs/namei.c:4673
#6  0xffffffff81004173 in do_syscall_64 (nr=<optimized out>, regs=0xffff8881977689c0) at arch/x86/entry/common.c:302
#7  0xffffffff81800088 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:238
#8  0x0000000000000000 in ?? ()

here's another stack trace at a different point in the rename() call:

#0  sf_rename (old_parent=<optimized out>, old_dentry=0xffff88804cd09f00, new_parent=<optimized out>,
    new_dentry=<optimized out>, flags=0)
    at /root/VirtualBox-5.2.28/out/linux.amd64/debug/bin/additions/src/vboxsf/dirops.c:798
#1  0xffffffff8127e4db in vfs_rename (old_dir=0xffff88804cc64720, old_dentry=0xffff88804cd09f00,
    new_dir=0xffff88804cc64720, new_dentry=0xffff88804cd09780, delegated_inode=<optimized out>, flags=<optimized out>)
    at fs/namei.c:4479
#2  0xffffffff81281aff in do_renameat2 (olddfd=-100, oldname=<optimized out>, newdfd=<optimized out>,
    newname=<optimized out>, flags=0) at fs/namei.c:4629
#3  0xffffffff81281d5c in __do_sys_rename (newname=<optimized out>, oldname=<optimized out>) at fs/namei.c:4675
#4  __se_sys_rename (newname=<optimized out>, oldname=<optimized out>) at fs/namei.c:4673
#5  __x64_sys_rename (regs=<optimized out>) at fs/namei.c:4673
#6  0xffffffff81004173 in do_syscall_64 (nr=<optimized out>, regs=0x0 <irq_stack_union>) at arch/x86/entry/common.c:302
#7  0xffffffff81800088 in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:238
#8  0x0000000000000000 in ?? ()

random links for reference material: https://myaut.github.io/dtrace-stap-book/kernel/fs.html https://sourceware.org/systemtap/SystemTap_Beginners_Guide/userspace-probing.html https://www.tldp.org/LDP/lki/lki-3.html https://doc.lagout.org/operating%20system%20/linux/Understanding%20Linux%20Kernel.pdf


random notes about setting up GDB for remote kernel debugging (sorry these are a mess, and this was really complex).

# virtualbox host pipe path
\\.\pipe\com1

# grub needs to be run with something like this line:
linux   /vmlinuz-4.19.118 root=UUID=cd58d41f-c708-47c4-b8fb-d2b8760dad9f ro quiet console=tty0 kgdboc=kbd,ttyS0,115200 nokaslr

# run from inside the VM: mount the shared fs
sudo mount -t vboxsf /media/sf_ -o exec

# with GDB attached, trigger the debugger. the VM will freeze and wait for the debugger to connect
echo g > /proc/sysrq-trigger

# type this magic string into console to breakout
# this is super-archaic, see https://www.kernel.org/doc/html/v4.13/dev-tools/kgdb.html for info
$3#33

# type this into GDB to connect
target remote localhost:3333

# other hints:
# -- make sure to disable vboxvideo kernel module
#    (causes issues with debugging serial console from main tty0 physical console)
# -- make sure vboxsf.ko is in the linux source dir you're running from
# -- .gdbinit needs substitute source path for virtualbox guest additions. can also try 'set substitute-path /root/VirtualBox-5.2.28/   ../from_guest/VirtualBox-5.2.28/'
# -- # KASLR changes the base address where the kernel code is placed at boot time. If KASLR is enabled (CONFIG_RANDOMIZE_BASE is set to y) in your kernel configuration, setting breakpoints from gdb will not work unless you also later add nokaslr to the kernel command-line parameters.

# run this bash command from the host windows OS to start debugging:
gdb vmlinux

# load symbols in gdb
(gdb) 
lx-symbols [takes forever, keep pressing enter]

some random info about how the rename works on the Host (windows) shared folder filesystem. I think this is probably not relevant but including for completeness:

way down after VBOX_CALL_INIT()
VGDrvCommonIoCtl() <-- gets you out of Virtualbox code in the linux kernel, and into the host OS.

# once on the host side of vbox, this causes the rename to happen in windows:
SHFL_FN_RENAME
vbsfRename() does the real work in windows IN vbsf.cpp (host side, there's another copy of this function client side, careful)

gets down to RTFileMove or RTDirRename in dir-posix.cpp

bin path-posix.cpp IS THE REAL DEAL THAT MOVES IT ON THE HOST OS
to find it, search for string "Check that the destination isn't a directory"

---

useful tools:

  • kdb
  • kgdb
  • systemtap

---

it's just a tedious amount of work to get all the setup in order to be able to run this, keep at it and I know we'll get to the bottom of it.

p.s. I'm available for contracting work if you want someone to dig into this more :) I'm not a kernel expert by any means, but I do alright :) If you have any questions about any of this though, hit me up.

Thanks! -Dom

comment:26 by Philipp Grafe, 3 years ago

Big thanks at Dom for digging such deep into this bug.

I am also visiting it once in a while eagerly waiting for a fix. Its getting even worse lately. I am using Vagrant Homestead for PHP Development and since Composer 2 its nearly unusable because Composer got much faster with file operations.

Currently my workaround is to downgrade the VirtualBox Guest Additions to version 5.2.44 which slows down the file operations, but its working.

Again thumbs up for Dom!

@Oracle: Please try to fix this as soon as possible.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use