You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the fuse mount we might run in the following situation:
User creates file over brig stage /file
User reads file over fuse. This will make the kernel cache (parts of) it.
User modifies the file over brig stage /file with new data.
User reads file over fuse again. This will return the old data coming from the page cache.
User waits some time.
User reads file over fuse again. This will return the new data.
Similar scenarios can be thought of regarding syncing and using the fuse file system. From my POV this is not critical since the situation resolves itself after a short time. There might be quite a bit of confusion though and also scripting is annoying due to that property.
Whenever a file is staged over catfs (and it's not coming from the fuse layer) then we gonna need to call fuse.InvalidateNodeData() on that particular file to make the kernel forget the cached pages and ask our filesystem for the new content. The implementation should be made in a generic way, to not couple fuse and catfs.
In the fuse mount we might run in the following situation:
brig stage /file
brig stage /file
with new data.Similar scenarios can be thought of regarding syncing and using the fuse file system. From my POV this is not critical since the situation resolves itself after a short time. There might be quite a bit of confusion though and also scripting is annoying due to that property.
Whenever a file is staged over
catfs
(and it's not coming from the fuse layer) then we gonna need to callfuse.InvalidateNodeData()
on that particular file to make the kernel forget the cached pages and ask our filesystem for the new content. The implementation should be made in a generic way, to not couplefuse
andcatfs
.(The issue was originally discovered here: #93)
The text was updated successfully, but these errors were encountered: