On 13 May '08, at 12:15 AM, Michael Vannorsdel wrote:
Basically there's no guarantee you'll get the same data that was in the file when you first mapped it if something else modifies or destroys it while it's mapped.
You're correct about modifications, but not about deletions. An open file descriptor counts as a link to a file, so the unlink(2) system call will not actually delete the file from disk because there's still a link to it. Once you close the mapped file, the last link goes away and then the file is actually deleted.
This is sometimes used as a technique for creating anonymous temporary files — create a temp file with open(2), then unlink(2) it so it doesn't exist in the directory tree anymore, then its yours to write/ read until you close(2) it.
While we're on the topic, it's worth noting that memory-mapping files on removable or network filesystems can be dangerous. If you read/ write a mapped memory location, and the kernel has to page it in, but the file's filesystem is no longer accessible due to a network issue or a yanked USB cable ... you get a bus-error. I've seen discussion of ways to handle this by installing a signal handler whenever you access mapped memory, but it would be pretty tricky to pull off. The conclusion was that it's only safe to memory-map files that are either (a) on the boot filesystem, or (b) in the user's home directory. (The latter might be on a networked filesystem, but if it ever gets disconnected, most of the upper layers of the OS and applications will be hosed anyway...)
—Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
