Opened 14 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 )
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)
Change History (26)
by , 14 years ago
| Attachment: | VBox-20110421-1939.log added |
|---|
comment:1 by , 13 years ago
comment:2 by , 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.
comment:3 by , 12 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 , 12 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 , 11 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...
comment:6 by , 11 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 , 10 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 , 9 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 , 9 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:11 by , 7 years ago
The problem still exists in VirtualBox 5.2.8. Seems to be the same as #15149 and #15897
comment:13 by , 6 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!
comment:14 by , 6 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 , 5 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 , 5 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:19 by , 5 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:20 by , 5 years ago
| Description: | modified (diff) |
|---|
follow-up: 22 comment:21 by , 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.
comment:22 by , 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 , 4 years ago
| Owner: | removed |
|---|---|
| Status: | accepted → assigned |
comment:24 by , 4 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 , 4 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 , 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.
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.