<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: 10.2 Finder Still Slow</title>
	<atom:link href="http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/feed/" rel="self" type="application/rss+xml" />
	<link>http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/</link>
	<description></description>
	<pubDate>Wed, 07 Jan 2009 05:04:33 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: slava</title>
		<link>http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/#comment-6</link>
		<dc:creator>slava</dc:creator>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid isPermaLink="false">/?p=24#comment-6</guid>
		<description>If it were 10.1 Finder, you'd end up waiting for a couple of hours ;) Does it makes you feel any better?



But yeah, something has to be done. Perhaps a haxie that will speed up move to trash operations in the Finder (as I am not hoping Apple will get their act together and fix it before next major OS update)?



=)</description>
		<content:encoded><![CDATA[<p>If it were 10.1 Finder, you'd end up waiting for a couple of hours ;) Does it makes you feel any better?</p>
<p>But yeah, something has to be done. Perhaps a haxie that will speed up move to trash operations in the Finder (as I am not hoping Apple will get their act together and fix it before next major OS update)?</p>
<p>=)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nute</title>
		<link>http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/#comment-7</link>
		<dc:creator>Nute</dc:creator>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid isPermaLink="false">/?p=24#comment-7</guid>
		<description>Your example would carry more weight if it was a real world example.  Yes, I know that there are times when you need to trash that many things, but you didn't need to here, you just did it to point out a problem.  Problem exists, fine, but don't act like you had to wait 45 minutes the other day.  if productivity is so important, why are you wasting so much time to point out that the Finder sucks?



And don't dismiss % rm.  The finder does have problems, but there are work arounds in the interim.  It's your own fault if you refuse to use what you know is there.



Not bitching about your gripes, as we know the Finder needs work, but its become pathological, man!</description>
		<content:encoded><![CDATA[<p>Your example would carry more weight if it was a real world example.  Yes, I know that there are times when you need to trash that many things, but you didn't need to here, you just did it to point out a problem.  Problem exists, fine, but don't act like you had to wait 45 minutes the other day.  if productivity is so important, why are you wasting so much time to point out that the Finder sucks?</p>
<p>And don't dismiss % rm.  The finder does have problems, but there are work arounds in the interim.  It's your own fault if you refuse to use what you know is there.</p>
<p>Not bitching about your gripes, as we know the Finder needs work, but its become pathological, man!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/#comment-8</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid isPermaLink="false">/?p=24#comment-8</guid>
		<description>This &lt;em&gt;was&lt;/em&gt; a real world problem. It's something that I actually wanted to do, and I didn't know beforehand that it would be so slow.



As it turns out, rm * doesn't work with that many files. So you have to rm them in batches, or know fancy shell tricks. I'm not actually sure how to do this with xargs because many of the file names contain spaces.</description>
		<content:encoded><![CDATA[<p>This <em>was</em> a real world problem. It's something that I actually wanted to do, and I didn't know beforehand that it would be so slow.</p>
<p>As it turns out, rm * doesn't work with that many files. So you have to rm them in batches, or know fancy shell tricks. I'm not actually sure how to do this with xargs because many of the file names contain spaces.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous Coward</title>
		<link>http://mjtsai.com/blog/2002/10/05/102_finder_still_slow/#comment-9</link>
		<dc:creator>Anonymous Coward</dc:creator>
		<pubDate>Wed, 31 Dec 1969 16:00:00 +0000</pubDate>
		<guid isPermaLink="false">/?p=24#comment-9</guid>
		<description>I've tried to copy thousands of files from a Windows server volume to my local disk and have experienced the beach ball. These were all good real world circumstances. I usually got it if I made the mistake of using my mac while the copy was happening, but I've gotten it even when I've left the computer untouched after starting the copy. I didn't even know I could wait 45 minutes and expect my Mac to snap out of it. And the terminal isn't a good fallback: cp, CpMac, rsync, that hfs version of rsync, and even tar all segfaulted on the same group of files. I suspect something wrong at the kernel level, but what the hell do I know? I'm an anonymous coward.
</description>
		<content:encoded><![CDATA[<p>I've tried to copy thousands of files from a Windows server volume to my local disk and have experienced the beach ball. These were all good real world circumstances. I usually got it if I made the mistake of using my mac while the copy was happening, but I've gotten it even when I've left the computer untouched after starting the copy. I didn't even know I could wait 45 minutes and expect my Mac to snap out of it. And the terminal isn't a good fallback: cp, CpMac, rsync, that hfs version of rsync, and even tar all segfaulted on the same group of files. I suspect something wrong at the kernel level, but what the hell do I know? I'm an anonymous coward.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
