Re: Symlink reporting

John Ogness wrote:
> Sami Tikka wrote:
> 
>> To correct myself: We solved this double-reporting problem so that we 
>> introduced a new event type to dazuko: LINK. When the 
>> inode_follow_link is called, it is reported to daemon as a LINK type 
>> event. When inode_permission is called, it is reported as OPEN or EXEC 
>> as usual.
> 
> 
> Hi,
> 
> I am not sure that adding a READLINK would solve your recursive-entry 
> problem. READLINK would probably come in addition to OPEN and not as a 
> replacement.
> 
> When "trusted applications" are supported (see 
> http://www.dazuko.org/files/dazuko_mold2005_presentation.pdf) you 
> shouldn't have this problem anymore. If we introduce new event types, it 
> needs to be because applications are really interested in these events 
> and not as a work-around for some desired functionality.

Actually, I was not talking about the recursive-entry problem here. I 
was referring to our symlink-handling implementation. The first version 
of our symlink-patch caused two ON_CLOSE events to be sent from driver 
to daemon, one where the file was the symlink and one where the file was 
the real file.

Later we modified our symlink-patch so that symlink access was reported 
as an ON_LINK event and the real file reported as an ON_OPEN event.

Anyway, I will send you the patch. Code speaks clearer that words. Or at 
least my words...

-- 
Sami Tikka                          tel: +358 9 2520 5115
Senior Software Engineer            fax: +358 9 2520 5013
F-Secure Corporation                http://www.F-Secure.com/
Be Sure.