A good friend just brought this issue to my attention, with could have lead to an awkward situation had I not known about it. Read on for the tale of woe, and the happy ending.
iCal 3.x (finally!) accepts attachments via drag and drop, so that they are at hand for that important meeting, etc. So far so very good. However, iCal doesn't actually link to the original file, but instead makes a copy, which it then buries in the ~/Library » Calendars » Attachments » random_string folder. This is fine, providing you don't edit your original file before that meeting, with the latest on the virus epidemic, impending Wall Street crash, etc. If you do, come meeting time, your old file version will pop up, sans new additions. Not the end of the world, providing you have time to scour your drive for the original file, without getting all red faced and sweaty. But that's what the attachment function was supposed to obviate, I thought.
The workaround is to create the attachment, then open the attachment from the iCal entry. Once open, Command-click on the file icon at the top of the window (to show the path to its location in the system), and then click on its enclosing folder from that pop-up menu to open that folder. Delete the file you find there (which is the one that iCal created), and create an alias in that folder to the original file by your favored method. I'm a big proponent of the Command-Option-drag method, but whatever floats your boat.
Now, you can edit the original file to your heart's content, knowing it will be there at your sweaty fingertips come crunch time.
I don't really see the logic behind Apple's implementation of the current attachment system unless it was rushed -- it just seems poorly thought out. Hope this tip saves someone some future aggravation.
Mac OS X Hints
http://hints.macworld.com/article.php?story=20080125072150140