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


Click here to return to the 'Current Implementation' 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 | # ]