Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: file monitored by kqueue isn't deleted


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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >file monitored by kqueue isn't deleted (From: Eric Ocean <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.