Opened 11 years ago
Closed 5 years ago
#12597 closed defect (fixed)
sendfile syscall returns cached content => Fixed in SVN / 6.0.6
Reported by: | MaximKulkin | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 4.2.18 |
Keywords: | sendfile | Cc: | |
Guest type: | other | Host type: | Linux |
Description
When using shared folder and copying file with sendfile syscall (either by just creating another file or sending content over network socket), the receiving end always gets the same content (the content that was in source file when sendfile called for the first time).
Repro steps:
- Setup a linux box with shared folder (tested on Ubuntu 13.04).
- Compile sendfile-copy.c (attached) inside VM:
make sendfile-copy
- Create a file "foo" in shared folder inside VM with contents "foo".
- Use "sendfile-copy" app from step 2 to copy file "foo":
./sendfile-copy foo bar
- Ensure that file "bar" contains string "foo":
cat bar
- Changed the contents of file "foo" to "bar". Ensure that file "foo" now contains "bar":
cat foo
- Copy file "foo" to "baz" with "sendfile-copy":
./sendfile-copy foo baz
- Inspect the contents of file "baz":
cat baz
You will see "foo" instead of "bar".
Attachments (1)
Change History (6)
by , 11 years ago
Attachment: | sendfile-copy.c added |
---|
comment:1 by , 10 years ago
comment:2 by , 9 years ago
+1
Related to #9069, which is less detailed but contains possible workaround.
comment:3 by , 9 years ago
comment:5 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | sendfile syscall returns cached content → sendfile syscall returns cached content => Fixed in SVN / 6.0.6 |
This should be addressed in 6.0.6, except for really really old kernels (< 2.5.30) where we cannot control what senfile does wrt caching. But even on those old kernels we will invalidate the cache if we notice st_mtime changes.
This prevents me from mounting volumes into docker containers in my development environment. They work initially, but when a file changes, everything messes up. The behavior I see is this:
If the file is changed but stays the same size we will call X:
If the file is changed to be a shorter amount of bytes Y:
If the file is changed to be a longer amount of bytes Z: