file monitored by kqueue isn't deleted

FROM : Eric Ocean
DATE : Fri Oct 15 22:05:13 2004

(BTW I'm using the well-written UKKQueue class--thanks Uli Kusterer.)

I'm monitoring an Adobe Illustrator file for changes using a kqueue. 
When saving a file, Illustrator first renames that file, then deletes 
it, and then writes a new file with the original filename/path. Fine.

So I get a rename notification, but it references the original path. 
This is really just a convenience; the UKKQueue class maintains a 
mapping between file descriptors and the paths you submitted to create 
those file descriptors.

Then I get a delete notification, but I will not get a subsequent write 
notification on the old path when the new file is written, presumably 
because kqueue monitors file descriptors (or their kernel equivalent) 
and the new file has a new file descriptor. Fine.

I'm currently removing the old path from the kqueue, re-adding the new 
file to my kqueue (using the old path), and then running my "file 
modified" code. This works, and is safe according to this message post: 
http://lists.apple.com/archives/darwin-development/2004/Feb/
msg00075.html

Here's the problem: the file Illustrator renamed is never removed. I 
know Illustrator is calling unlink() after the rename, because that's 
what causes the delete notification to be sent according to the kqueue 
man page. However, after I terminate my program, the file remains. I'm 
assuming that because kqueue had an open file descriptor (or something 
similar down in the kernel), it prevented the file from being truly 
removed while the kqueue was running. Okay, then once I close the 
kqueue, the file should then have no further kernel references and be 
deleted, right?

And even if somehow my program had a file descriptor open to the old 
file, when I quit my program, the file descriptor should be closed and 
the unlink should succeed, shouldn't it?

Well, since that isn't happening, I'm thinking, I'll just use a hammer 
and call unlink() on the old file myself. No problem...except that I 
don't know the file name it was renamed to, and unlink() takes a path! 
AFAICT after googling for a while, there isn't a function with the 
unlink() functionality that takes a file descriptor (nor should there 
be, when you think about it).

I'm out of ideas. Manually doing an unlink() on the renamed file seems 
like a hack to me. I don't understand why the file isn't being removed 
to begin with. And I'm not  sure how to go about finding the file's 
renamed path if I go down that path. The kqueue API doesn't appear to 
give you that handy piece of information; perhaps I just missed it. I'm 
guessing I would have to loop over the inodes of the files in the 
directory until I found one with the same inode as the old file. That's 
pretty low-level for such a simple piece of functionality.

Thanks for any assistance.

Regards,

Eric Ocean