Ticket #5251 (closed defect: fixed)
vboxsf has a delay after deleting files until they are deleted => Fixed in SVN
Reported by: | KotH | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 3.0.8 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Windows |
Description (last modified by frank) (diff)
When using a windows xp host and a linux guest (debian/testing 2.6.30.2) using shared folders, there is a slight delay after a file is deleted until it really is deleted, leading to a race condition. This becomes visible when using svnadmin load, which creates transaction files in a directory and deletes them at the end:
01 open("secureusbstick/db/transactions/0-0.txn", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4 02 fstat64(4, {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 03 fcntl64(4, F_GETFD) = 0x1 (flags FD_CLOEXEC) 04 getdents64(4, /* 5 entries */, 4096) = 144 05 lstat64("secureusbstick/db/transactions/0-0.txn/.", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 06 lstat64("secureusbstick/db/transactions/0-0.txn/..", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 07 lstat64("secureusbstick/db/transactions/0-0.txn/changes", {st_mode=S_IFREG|0777, st_size=0, ...}) = 0 08 unlink("secureusbstick/db/transactions/0-0.txn/changes") = 0 09 lstat64("secureusbstick/db/transactions/0-0.txn/next-ids", {st_mode=S_IFREG|0777, st_size=4, ...}) = 0 10 unlink("secureusbstick/db/transactions/0-0.txn/next-ids") = 0 11 lstat64("secureusbstick/db/transactions/0-0.txn/node.0.0", {st_mode=S_IFREG|0777, st_size=140, ...}) = 0 12 unlink("secureusbstick/db/transactions/0-0.txn/node.0.0") = 0 13 getdents64(4, /* 0 entries */, 4096) = 0 14 lseek(4, 0, SEEK_SET) = 0 15 getdents64(4, /* 5 entries */, 4096) = 144 16 lstat64("secureusbstick/db/transactions/0-0.txn/.", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 17 lstat64("secureusbstick/db/transactions/0-0.txn/..", {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0 18 lstat64("secureusbstick/db/transactions/0-0.txn/changes", 0xbfc9faf0) = -1 ENOENT (No such file or directory) 19 close(4) = 0
The directory is opened at line 01, on line 04 the contents are retrieved (3 files, and the directories . and ..). On lines 08, 10 and 12 the files are deleted. on line 15, svnadmin checks whether the directory is now empty. Note that it returns again 5 entries, like it did on line 01, although 3 files have been deleted. As the directory is not empty, svnadmin tries to delete the files again, which fails (line 18), which in turn causes svnadmin to abort, as it couldn't delete the file.
Change History
comment:4 Changed 13 years ago by jimduchek
I can verify this is a problem on Linux hosts as well. I'm a little unclear as to why this creates an infinite loop, though -- I would think that _eventually_ getdents64 would return that the directory is empty. However, that doesn't seem the be the case. Are there any known workarounds?
comment:5 Changed 13 years ago by volrek
bug is still present in (host) VirtualBox OSE 3.1.6 on fedora x86_64, (guest) debian 5.04, 2.6.26-2 686. there are 2 workarounds i know of:
- don't use rm -rf but rm -r. the latter returns failure assuming it didn't delete a directory when it actually did. like so:
panic:/mnt/shared_folder# rm -r 3.9.0 rm: cannot remove '3.9.0/usr/share': No such file or directory rm: cannot remove '3.9.0/share/man': No such file or directory ... panic:/mnt/shared_folder# rm -r 3.9.0 rm: cannot remove '3.9.0/usr': No such file or directory
so you could loop over rm -r until done
2nd workaround: find shared_folder -type f -exec rm {} \;, after that rm -rf will succeed
btw: the same problem occurs with vmware workstation and their shared folders.
i'd very much like this to be fixed - has anybody got an update on this issue?
comment:6 Changed 13 years ago by frank
This could be an SMP issue. The guest is performing a HGCM call to the host asking for the deletion of the file and while this is done, another guest core will still be able to open this file. Anybody observing this problem with non-SMP guests?
comment:7 Changed 13 years ago by KotH
I doubt that it is an SMP issue. If it was, them rm -rf wouldn't go into an endless loop, but would succeed as soon as the deletion on the host side is communicated back to the guest. But apperantly, it is not. Also i ran only one single guest, and only one application in it that was accessing those directories (namely the rm -rf).
I found another way to reproduce this bug:
Create a directory structure with a couple (10-40) files per directory on the linux guest in the shared folder. Do an rm -rf from the linux guest. rm will loop in one of the directories with the following sequence:
getdents(x, <some entries>, 4096)
unlinkat(..) = -1 ENOENT
unlinkat(..) = -1 ENOENT
unlinkat(..) = -1 ENOENT
unlinkat(..) = -1 ENOENT
...
getdents64(x, <0 entries>, 4096)
lseek(x, 0, SEEK_SET)
getdents(x, <some entries>, 4096)
unlinkat(..) = -1 ENOENT
(continue ad infinitum)
This basically means, that rm -r does not work in shared folders, but ends up in an endless loop.