Home
I use Calendar.app on Yosemite 10.10.2. As you know, individual Calendars and Reminders are also stored just below the Calendar.app in the Applications Folder. As the Calendars and Reminders age, I remove the older ones by putting them in the trash. When the trash is emptied, each Calendar and Reminder shows at least 1,000 items and often 1,200. The emptying process takes a long time. Although there is a copy in Time Machine, I store this extra copy in the Applications Folder as insurance since I rely heavily on my Calendar.

Is there any way to decrease the size of the trashed Calendars and Reminders or any other way to shorten the emptying process? I often find it inconvenient to have to wait to send some other document to the trash. In previous versions of the Mac operating system, another trash window would open beneath the one being emptied, but Yosemite seems to have discontinued that feature. Advice would be deeply appreciated.
Try to compress the items you'd like to delete (Control- or Right-click > 'Compress...'). Combining several items for compression into a single archive speeds up deletion even more. It's possible that compressing takes as much or more time as the deletion of the uncompressed items, but that's something you'll find out soon enough.
it takes longer to delete many files than one. some things are "packages", sort of meta-folders, that contain many things but show up as one. (application packages and iPhoto Library are great examples) Deleting a large package could take several minutes, as a few hundred thousand files are actually being deleted.

In most cases, the size of the file is irrelevant to the time required to delete it. There's just some fixed overhead per file that you have to deal with.

(and then there's Finder's habit of adding things up before beginning the delete, so it can tell you how much data you're about to trash, which IMHO is a waste of my time)

PROTIP:

to quickly delete a lot of files, create a TRASHME folder on your desktop. Drag everything you want to delete into that folder. open terminal.

type: rm -rF
and a single space after the "-rF". DO NOT hit return yet.

drag and drop TRASHME into the terminal window. it will add its path after -RF . Press return. There will be no progress indicator, you will simply get another prompt when it has finished.

Can delete in anywhere from 1/4 to 1/20th the time Finder normally requires.

RM is a dangerous command, use with care. As demonstrated above, it can delete files very quickly. You might not like what you accidentally told it to delete.


There is another advantage to RM. If it hits a file it can't delete, it'll cough up an error and continue, unlike Finder that will either (A) prompt you or (B) whine and abort. RM will leave you with only the file or files that it could not delete, usually because they're locked. RM will also delete files the OS has marked as "in use", which frequently happens when apps crash. Finder won't empty the trash with them in it until you restart your computer. RM just blows them right away.

Snowy's rm man page does not offer the -F option, only -f; is there a difference?

Thanks.
I thought I'd start out cautiously before attempting the Terminal stuff. I compressed the files in situ in the Applications folder. Compressed versions were created, but the originals remained in their original form. In other words, the originals spawned compressed copies, but I couldn't get rid of the originals.

It appears that I can't follow your suggestion until I can prevent making a compressed copy. Is it possible that the Calendar app is a sort of rogue app?
Originally Posted By: JoBoy
It appears that I can't follow your suggestion until I can prevent making a compressed copy. Is it possible that the Calendar app is a sort of rogue app?

No, Calendar is no rogue app, and you're completely right in that the default procedure with Apple’s Archive utility is to compress a copy of the selected items. My bad for not remembering this, the more so since I ran into it myself fairly recently. The thing is, I also recall using a compression utility (quite some time ago) with a prefs option to remove the original when compressing files/folders, but that option is not available with Apple’s Archive util (/System/Library/CoreServices/Applications/Archive Utility.app). Without it my suggestion is dead in the water. It only shows the effect of deleting a single big file vs. many small ones.
I made the folder named TRASHME and moved a Calendar and Reminders file into it, but that only created a duplicate Calendar and Reminders file in TRASHME while the original file remained in the Applications Folder next to Calendar.app. How do I prevent the duplicate from being made?

I'm using Yosemite 10.10.2.

Quote:
As you know, individual Calendars and Reminders are also stored just below the Calendar.app in the Applications Folder.

Can you please elaborate on this statement? What do you mean by "just below?" And do you really mean the Applications folder? User data is generally not stored anywhere outside of the user's Home folder. In my Yosemite installation, individual Calendars and Reminders are found in my Home folder's Library -> Calendars folder—nowhere near the Applications folder.
I meant what I said. Calendars and Reminders are stored in my Applications Folder just below Calendar.app.

I searched my Library-> for a Calendars folder, but there was no such folder there. I've been doing this ever since I abandoned Entourage a few years ago and have gone through a few updates of Calendar.app. I've never known it to be any other way. I'm just reporting my experience. I have no idea how things SHOULD be.

The only way I can avoid the duplicate problem mentioned in this thread is to move the outdated Calendars and Reminders files directly to the Trash when Trash isn't already busy.
> The only way I can avoid the duplicate problem mentioned in this thread is to move the outdated Calendars and Reminders files directly to the Trash when Trash isn't already busy.

Have you tried "rm"ing them as per V1, but individually, rather than collected in a folder?

Okay, I figured out what you did, once I found your Calendar Disaster thread.

When you made the original backup using the Export > Calendar Archive… command in Calendar's File menu, the Save dialog that opened had Applications as the current default Save location. This location is not intrinsic to Calendar's Export function. Case in point: when I retraced your footsteps as outlined in the Calendar Disaster post, the Save dialog defaulted to my Documents folder.

I believe that in any application, if you're opening a particular Save or Open dialog for the first time, the default location is most recent location where you saved or opened any file. The point is, Calendar.app has no built-in mechanism directing exported data to the Applications folder; the Save dialog for your initial export just happened to be pointing there. Following that initial Save, though, the application remembers it and defaults to it automatically. So you've been backing up to a less-than-ideal location. It would be much better to back up to a location somewhere within your Home folder, e.g. Documents.

But to answer your specific question: to move rather than copy the files you want to delete that are currently in the Applications folder, hold down the Command key while dragging them to the desired location.
OK. I agree with everything you've said. I'd rather NOT have them backed up to the Applications Folder, but it's strange that, following the Calendar Disaster episode, I've been able to get along as long as I have without any issues until tonight. On the other hand, the only way I've dealt with the old files is to delete them one at a time via the Trash. Tonight, I tried to do three at a time and things didn't work as I had hoped.
I have now created a Calendars and Reminders Folder in my Documents Folder. Two separate Calendars and Reminders files are enclosed therein. I'm going to bed now, but will see tomorrow if I have any further problems to solve.

Thanks for your persistence. I really appreciate it and also the information you shared. This forum is still the best one I know of and this kind of problem solving just can't be done on other places I've looked at.
Couldn't sleep. Went back at it. As advertised, the Calendars and Reminders file does make it to the Desktop without making a copy when the Command key is on during the movement. BUT, when I right-click The Calendars and Reminders file on the desk top and select Compress Calendars and Reminders, a compressed version is created leaving the original file unscathed. Doing Comand-right click, blocks the effect of the right click. Nothing happens. When I go to Finder -> File with Command key pressed or not pressed, clicking the Compress Calendars and Reminders also yields a compressed duplicate. I also tried the suggested Terminal solution, but I couldn't get it to do anything. It didn't like the input I gave it despite three tries.

My original question was: Is there any way to decrease the size of the trashed Calendars and Reminders or any other way to shorten the emptying process?

Apparently, the answer is no. My apparent only choice if I'm sick of the long emptying process is to forget this extra set of Calendars and Reminders and rely only on the two sets of Time Machine backups that I have using two backup disks.

Again, thanks for the effort. It was very interesting and I learned a lot.
> I also tried the suggested Terminal solution, but I couldn't get it to do anything. It didn't like the input I gave it despite three tries.

Please try one more time and copy & paste your Terminal output into a post so we can maybe determine what went wrong.
Originally Posted By: alternaut
The thing is, I also recall using a compression utility (quite some time ago) with a prefs option to remove the original when compressing files/folders, but that option is not available with Apple’s Archive util (/System/Library/CoreServices/Applications/Archive Utility.app). (Emphasis added)

It is in Snowy. (/System/Library/CoreServices/Archive Utility.app) Found it here. (Edit: Maybe the pref changed with the location.)

I also found Keka (Donationware or $1.99/App Store), which has the appropriate pref and offers more compression options. (Edit: There's a glitch in Keka, and the "delete" pref doesn't stick, but "move to trash" does.)

Edit: This is to suit JoBoy's needs: Keka's delete pref does work, but only when its window is open.

Quote:
The thing is, I also recall using a compression utility (quite some time ago) with a prefs option to remove the original when compressing files/folders, but that option is not available with Apple’s Archive util (/System/Library/CoreServices/Applications/Archive Utility.app).

Actually, it is: Archive Utility's Preferences window in Yosemite appears identical to that in the screenshot in artie's linked article.
You are correct, but I should have been more precise, because it’s not quite what I meant. Moving the original files to the Trash only keeps the problem of the slow deleting process alive. What I meant with ‘removing’ was ‘trashing’. Obviously, that could be as slow as manually trashing files, in which case we’d be back at Start again. But my recollection was that this compression pref trashing was almost instantaneous, possibly along the lines of what V1 described with his Terminal procedure. The last time I ran into this I looked for compression utilities with this instant delete-of-original(s) option, but didn’t find one among freebies and trial versions before I got distracted by something else.

Having read your post, I revisited Archive Utility’s prefs, and I tried the only option that might do what I wanted, i.e., delete files archived after archiving. Unfortunately, this did not work as expected: both original folder and the zipped one stayed around, in my case on the desktop. I wonder if I misunderstood the meaning of this option (I would have used the word ‘original’ instead of ‘archived’), or that it 'just' didn't work.
Originally Posted By: alternaut
Having read your post, I revisited Archive Utility’s prefs, and I tried the only option that might do what I wanted, i.e., delete files archived after archiving. Unfortunately, this did not work as expected: both original folder and the zipped one stayed around, in my case on the desktop. I wonder if I misunderstood the meaning of this option (I would have used the word ‘original’ instead of ‘archived’), or that it 'just' didn't work.

Hmmm... In Snowy, the Archive Utility (v 10.6 (47)) pref you selected does precisely what you're looking for, i.e. it makes my original (on either my desktop or another volume) disappear more or less instantaneously after archiving. (Edit: Time for a bug report?)

I was going to suggest that you try Keka, but I just used it to .zip a coupl'a folders with the "delete" box checked, and it only moved the originals to the trash. Now, I dunno. confused (Edit: On the other hand, though, Keka did a better job of compression than AU in my test.)

(GUI Tar offers more compression options than Keka, but neither "move to trash" nor "delete".)
Your aside belongs in a new thread.
Thanks for the offer, but I just don't want to go any farther into that stuff. It's obviously an unmet need in the real world that has not been met by the major players. I used to do a lot of experimenting, but not any more.
Originally Posted By: artie505
Snowy's rm man page does not offer the -F option, only -f; is there a difference?


my bad. I meant to type -Rf. Actually they've made -r work the same as R now. (flags are almost always case-sensitive)

so you can just go with -rf
Got it; thanks.
© FineTunedMac