Re: file monitored by kqueue isn't deleted
Re: file monitored by kqueue isn't deleted
- Subject: Re: file monitored by kqueue isn't deleted
- From: Jim Magee <email@hidden>
- Date: Mon, 18 Oct 2004 13:06:36 -0400
On Oct 15, 2004, at 7:11 PM, Eric Ocean wrote:
I'm monitoring an Adobe Illustrator file for changes using a kqueue. When saving a file, Illustrator first renames that file, then creates a new file with the original filename/path, and finally deletes the old, renamed file. Fine.
So I get a rename notification, and 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 and the new file has a new file descriptor. Fine.
Correct. The kqueue notifications are about the files identified by open file descriptors. Your monitor application doesn't have a file descriptor open for the new file Illustrator creates with the same path. So any modifications to that new file are not seen until you re-open the new file at that path and watch for events on it.
I'm currently removing the old fd from the kqueue, re-adding the new fd to my kqueue, 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 and the fd, the file should then have no further kernel references and be deleted, right?
An open file descriptor should never keep the file from being unlinked from a given path. Using kqueue with that file descriptor should have no bearing on that. I'd love to know what version(s) (OS, Illustrator, etc...) of the various software you are using, which filesystem type you are testing on (presumably HFS+ w/ journaling) and a scenario for it reproducing the bug. If you could, please report this via a bugreport.
This should just not happen. What should happen is that the unlink succeeds. The file contents wont go away until that last reference goes away (the one held by your monitor app). But the file should no longer be reachable through that one path that was unlinked. If that was the last path to the file, it will just be unreachable from any (public) path. Once the last open file descriptor reference goes away, the space occupied by the file on disk will be scheduled for reclaim. Different filesystems handle that process differently - but none should deny the unlink in the first place.
--Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden