id summary reporter owner description type status component version resolution keywords cc guest host 5251 vboxsf has a delay after deleting files until they are deleted => Fixed in SVN 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. " defect closed shared folders VirtualBox 3.0.8 fixed Linux Windows