vboxsf has a delay after deleting files until they are deleted

[Attila Kinali]

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.

[Attila Kinali]

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.