file sharing painfully slow

[Chris Murphy]

On Mar 20, 2007, at 11:23 PM, Dan Shoop wrote:

>> Plus, your analogy fails to withstand scrutiny. Your assumption is  
>> that cream is a good thing, and more cream is inherently better.  
>> Extra cream vs. too little cream, in either case it's the wrong  
>> amount.
>
> Nowhere did I suggest that you flood yourself.

The fact remains your analogy fails to withstand even superficial  
scrutiny.
>
>> I need to do something that should take all of 30 seconds, yet I  
>> have to wait almost 5 minutes with a beachballing Finder.
>
> Then you have an issue which merits further investigation. But you  
> just want to bitch and not really sniff and find out what's happening.

That's laughable. You say here it merits further investigation as  
though there is in fact a problem, and yet in this same email you  
state that it is working.

> And you lump it on "the Finder" as if that's the culprit and it's  
> not an issue of Cocoa and Carbon frameworks.

The problem is being manifested at the Finder level. The culprit  
actually existing in some framework is of exactly zero interest to me.

> The concepts of being able to tell when files change takes  
> metadata. You can't have that on FTP-like data connections like  
> you're suggesting. But if you want that use an ssh filesystem. And  
> you can still then use the Finder.

Your solution is that I must accept stupidity in order to get  
features. Yet I get the features I need without the primary  
navigation application hanging on at least two other operating  
systems in the same situation. The Finder lacks the granularity to  
turn off a "feature" that serves exactly no purpose but to cause the  
downloading of redundant and useless information. The local JPEG icon  
is perfectly sufficient, it isn't necessary for any sort of positive  
UE to download even one copy from the remote server, let alone 900  
copies of the same thing.
>
> But if you want AFP and annoucements you can't have your coffee black.

And I don't want it black. I want it without things that make no  
sense to anyone who is clearly operating with all thrusters. I will  
propose that anyone who wants unimportant, unhelpful, redundant  
metadata that will beachball the Finder for 1/3 of a second per file  
is irrational.
>
>>  It's indefensible and your position is just totally untenable, Dan.
>
> How so?

Because it's an irrational position. You have claimed that the Finder/ 
AFP are working just fine and dandy, taking 5 minutes of complete  
Finder inoperability is completely normal isn't merely an  
uncompelling argument. It's crazy.

>
>>  I no longer have coffee with some cream. I have a pint of cream  
>> with an ounce of coffee in it. It's completely the wrong order and  
>> saying it's working correctly is just patently absurd.
>
> Is it working? Yes. Done.

It isn't working because it mandates unreasonable inefficiency and a  
bad user experience.

>> By all means feel free to compute the amount for 900 images. I  
>> seriously doubt it approaches anywhere near 10MB.
>
> What butt did you pull that out of? Where do you get that it's  
> transferring 10MB for a directory listing?

Time and bandwidth for the operation to complete. It's consistent  
with 900 copies of a 44k 64pixel generic JPEG icon being downloaded.

> Then use a filesystem transport that meets your black coffee needs.  
> It's not like it's hard to do.
>
> You complain like screwdrivers should hammer nails.

Yeah and apparently you'll defend anything in the OS as working  
correctly if you think this is acceptable behavior.


Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"