Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: Create updateable iCal attachments Apps
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.
    •    
  • Currently 3.00 / 5
  You rated: 4 / 5 (6 votes cast)
 
[13,410 views]  

10.5: Create updateable iCal attachments | 11 comments | Create New Account
Click here to return to the '10.5: Create updateable iCal attachments' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Current Implementation
Authored by: jediknil on Nov 07, '08 09:29:41AM

I would guess that the current implementation is designed to prevent data loss for users who add an attachment and then delete the original file, thinking it is safely attached. Keeping calendars in line with e-mail certainly seems reasonable to me, especially if it's a shared calendar.

But it would be nice if there was a way to, say, command-option-drag an attachment, which would make an alias instead.



[ Reply to This | # ]
Current Implementation
Authored by: Anonymous on Nov 07, '08 12:50:19PM

You won't have heard of hard links then?

And neither, plainly, has the team of dummies that implemented this stupid iCal feature.



[ Reply to This | # ]
Current Implementation
Authored by: taxi on Nov 07, '08 05:32:01PM

Most Apple (and many 3rd party) applications fail badly when trying to use hardlinks, for the reason that instead of rewriting the file, the data is saved to a new file, which is then copied over the top of the original file.

In this instance, hardlinks are worse than useless, as you end up with two copies of the file.



[ Reply to This | # ]
Current Implementation
Authored by: PatrickS on Nov 09, '08 12:00:00PM

Hard links don't work across different volumes/file systems, so as soon as you are using more than one disk, you loose.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: Dr. T on Nov 07, '08 10:10:11AM

There is confusion between attaching a (static) file to something (such as a calendar entry or an e-mail) and linking to a changeable file. Apple provided an attachment feature, not a linking feature. Each has advantages and disadvantages. I believe that iCal should offer both (with clear explanations of the differences).



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: taxi on Nov 07, '08 05:45:24PM

iCal does offer both.

If you drag a file to the attachments… link, then you copy an attachment.

If you drag a file to the url field, then it will place a link to that file there.

The only annoyance is that you can only have one url per iCal entry. (But you can link to a folder, which may have several documents).

I personally use this feature all of the time. Work I have to bring to a class gets a link in the iCal entry for that session, so I can quickly load it up at class.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: Dr. T on Nov 08, '08 10:31:36AM

A URL link is not a full-featured link. A URL link breaks if you move or rename the file. A true link can handle name and location changes.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: kiltbear on Nov 07, '08 10:33:58AM

Great catch!

Easier solution: Make an alias/link of the original file, and drag the alias/link to the appointment.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: kiltbear on Nov 07, '08 11:17:16AM

oh, and you can delete the alias/link after dragging it over.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: Anonymous on Nov 07, '08 12:51:34PM

That's because it made a copy of it. So yes.



[ Reply to This | # ]
10.5: Create updateable iCal attachments
Authored by: xsundeep on Nov 09, '08 05:26:57AM

The mail alias/symlink method seems to be the safest of the lot. Also, we've had very unexpected results with other calendar programs that have allowed this. I think the calendar programs are not really built to be filesystems. For example, M$ (yes, yes) fully expects calendars to be about 1Mb's worth per year (or so).

We've recommended that our users copy&paste text into calendar items rather than use full attachments.

All evidence is anecdotal, so YMMV.



[ Reply to This | # ]