Re: resolving full path when creating a new file on freebsd 4.x (and more)

John Ogness <[email protected]>
Newsgroups gmane.linux.dazuko.devel
Message-ID <[email protected]>
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).


> Here is a patch for freebsd_get_full_fileinfo() that tries to resolve the
> first parent directory of a file if the file itself does not exist (ENOENT).

Thanks. I will check it out this weekend.


> 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


> If indeed the other syscalls should be handled as well, I am willing to
> provide patches for that.

That would be great!


> I have more questions and suggestions, but they will come later.

I am always open to new ideas.

John Ogness

-- 
Dazuko Maintainer
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.