On 9/13/05 11:32 AM, Matt Gough didst favor us with:
> Whilst testing my app's ability to cope with documents that cause
> CFURLCreateFromFSRef to fail due to path length restrictions I
> thought I'd see how other stuff in the system copes with such files.
>
> In short, the answer is appallingly, so I am thinking that maybe I
> really shouldn't care. From my own testing it seems that no-one would
> actually be able to work with such a document anyway. (FYI - my app
> doesn't create or edit any documents, it just works with them in
> other ways.)
>
> E.g.
>
> Finder
> Once you drag something into a folder that makes its path too long,
> you can no longer drag it out again.
>
> You can't use Open With as that calls down to
> LSCopyApplicationURLsForURL and the URL is duff. (Why no
> LSCopyApplicationURLsForRef ?)
>
>
> Cocoa apps
> You cannot open any such document or save a document to such a place.
> No user feedback apart from dimmed Open/Save buttons in Open/Save
> dialogs. Double-clicking them in the Finder does nothing.
>
>
> Carbon apps
> You can double-click them to open them, but attempting to use Nav
> Services to open or save them will crash the app whilst trying to
> update the Recent Documents:
>
> 0 com.apple.CoreFoundation 0x90737b9c CFURLGetString + 52
> 1 com.apple.NavigationServices 0x930770a0
> TBrowseDialog::SaveDialogPrefs() + 876
> 2 com.apple.NavigationServices 0x93076b28
> TBrowseDialog::TerminateDialog() + 88
> 3 com.apple.NavigationServices 0x93076a90
> _NavDialog::TerminateWithUserAction(unsigned long) + 72
>
>
> Spotlight
> Never finds such a file.
>
>
> Classic apps
> No problems at all :)
>
>
> So given that I haven't heard of hoards of users storming Infinite
> Loop with pitch forks and burning sticks complaining about these
> problems I really do think that it is a moot point.
I disagree. People aren't storming Redmond over limitations in Windows
either. They weren't storming Infinite Loop asking for windows with shadows.
I don't even remember seeing large unruly crowds clamoring for Unix under
the Mac OS or Intel in their Macs. IMO, we need to provide the best possible
experience for all users, and our aspirations should be higher than "better
than Windows" or "no one's complaining."
> Any comments?
- First, let me say I appreciate the time you spent to test these issues and
share the result here.
- I think you should file bugs against all of them.
- People often don't complain when they feel it's futile and they can work
around the problem. We have no way of knowing how often people limit their
directory structures to accommodate this issue. The average user may never
run into this, but I've learned there are a lot of professionals with
extreme needs (by normal standards) for organizing files and folders. People
with hundreds of thousands of images kept in complex directory hierarchies,
for example. But you don't really need that, because I've run into problems
from this in the past myself. You adapt. But should you have to adapt to
something like this when you've spent a couple thousand dollars on a
state-of-the-art computer and OS?
- Why are we willing to sell this OS as a modern, state-of-the-art OS and
then tell people they need to accommodate 35 year old limitations in Unix?
Unix people think this is fine, but they're the same people who think vowels
in function names are a luxury and that the Shift key is for weenies.
They've long since adapted to the limitations imposed by Unix, so they don't
see that for ordinary people, these limitations make no sense and are at
times frustrating.
- I think this is a miserable step backwards from what we had before Mac OS
X. In these days of multi-GHz processors, multi-Gigabytes of RAM, and hard
disks with hundreds of Gigabytes of space, I think it's absurd to be tied to
a 35 year old limitation like this. We should see fewer limitations in this
arena than we did in Mac OS 9 (or 1970s Unix), not more.
Those, per your request, are my thoughts. ;-)
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
