Re: [Dazuko-devel] No bugs, but a blocking close patch

[John Ogness]

Tikka, Sami wrote:
> This patch makes application calling the close syscall block while dazuko
> daemon(s) processes the access request.

Hi,

Older versions of Dazuko used to do it this way. With 2.1.0 it was
changed because there is a problem with the data not being flushed to
the file before the close(). If you make a test registered program that
outputs the contents it "sees", you will notice that (with this patch)
for ON_CLOSE events it doesn't see the bytes most recently written to a
file before closing.

It was decided that it was more important for a registered application
to be able to see the full content, than to be able to postpost the
system call. (Blocking the system call makes no sense, but I understand
the desire to postpone it until the registered application is finished.)

With DazukoFS we will have a finer control over this situation since we
will be working with the file system directly.

Another interesting feature (which has been suggested several times in
the past) is that Dazuko offers pre and post processing for all event
types. This would allow the application developer to decide what they
want. But in my opinion, this would just be a workaround for the current
ON_CLOSE issues. Such workarounds shouldn't be necessary with DazukoFS.

The events *should* all be triggered as pre-events. This makes the most
sense. For ON_CLOSE, it should mean that the data has already been
flushed, but the call to close the file has not returned. With syscall
hooking this does not appear to be possible, but with DazukoFS it should be.

John Ogness

-- 
Dazuko Maintainer