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 _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
