vboxsf has a delay after deleting files until they are deleted => Fixed in SVN

[KotH]

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.

[KotH]

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.

[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?

[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:

1. 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?

[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?

[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).

[frank]

Should be fixed in SVN as of r30150.