[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dazuko-devel] resolving full path when creating a new file on freebsd 4
From: |
Patrick Bihan-Faou |
Subject: |
[Dazuko-devel] resolving full path when creating a new file on freebsd 4.x (and more) |
Date: |
Fri, 27 Aug 2004 15:39:44 +0200 |
Hi,
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.
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).
The provided patch has been slightly tested on a FreeBSD 4.9 system with
good success so far.
Also, while there, I have replaced the vrele calls that were following
NDINIT/namei calls with more adequate NDFREE() calls that also free the
memory that could have been allocated during the namei() call.
Now I have another question regarding the closed/modified event:
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:
- write() (already handled)
- writev() (handles scattered buffers for a single write operation)
- pwrite() (write at a specific offset)
- aio_write (asynchronous IO call)
Only the first syscall is handled and none of the last 3. Wouldn't that
invalidate the usefulleness of the closed-modified event ?
If indeed the other syscalls should be handled as well, I am willing to
provide patches for that.
I have more questions and suggestions, but they will come later.
Patrick.
dazuko_freebsd.c.patch
Description: Binary data
- [Dazuko-devel] resolving full path when creating a new file on freebsd 4.x (and more),
Patrick Bihan-Faou <=