RE: [Dazuko-devel] resolving full path when creating a new file onfreebsd 4.x (and more)

[Patrick Bihan-Faou]

Hi,



> Patrick Bihan-Faou wrote:
> > Testing dazuko 2.0.3-pre4 on freebsd I noticed that I was never
> getting the
> > OPEN/CLOSE events for files that were non-existant previously.
> After some
> > investigation, I found that when the file does not exist, the
> namei() call
> > in freebsd_get_full_fileinfo() (called from
> xp_file_struct_check()) returns
> > ENOENT leading in the name not being resolved.
>
> Yes, as you noticed, name lookups can only be successful for
> existing files.
> We worked around this issue by making newly created files
> generate post_open
> events (ie. an ON_OPEN event is generated after the open was completed).


Well would'nt generating the ON_OPEN event after the open has completed have
a nasty side effect ? Namely the file would already be created even if the
dazuko daemon decided that the open should be blocked.



> > To support the closed-modified event, dazuko monitors the write
> system call.
> > However in FreeBSD there are at least 4 calls that can modify a file:
> >
> > [snip]
> >
> > Only the first syscall is handled and none of the last 3. Wouldn't that
> > invalidate the usefulleness of the closed-modified event ?
>
> Yes you are correct. I am unhappy with this implementation of noticing
> changed files (because of the overhead). I am also unhappy that ON_CLOSE
> events are based on matching file descriptors. Both of these should be
> seriously considered, but it is very limiting at the system call
> level. This
> will be more easily and efficiently handled once DazukoFS is released.
>
> http://lists.gnu.org/archive/html/dazuko-devel/2004-08/msg00004.html
>
>

Yes I have seen this announcement. Is FIST portable to FreeBSD as well ? If
yes that's probably the best solution.

In the meantime I'll handle the missing syscalls.

>
>
> > I have more questions and suggestions, but they will come later.
>
> I am always open to new ideas.



Well for one I'd like to see more type of event monitored (this is specific
to an application I am considering):

- renames (needs a change in the event structure to support 2 filenames as
noted in a previous thread)

- symlink/hardlink creations/modifications (I did not look at what would be
needed to implement that for now, but like for rename having to filenames in
the event structure seems to be a must)

- more precise information on the written parts of the files (i.e.
offset+len)


Patrick.