I have a vague recollection that we had to escape the ":" with a
backslash. Shouldn't have to, but clearly it's the colon that's giving
you grief.
I'm not near any code to check how we're doing it, but I tried our app
(which uses CreateMovieStorage), specifying a slash in the filename
(which gets changed to a colon) and it worked as expected.
-- Bob
On Sun, Jun 1, 2008 10:29 PM, Seth Willits <email@hidden> wrote:
>On Jun 1, 2008, at 7:36 PM, Bill Monk wrote:
>
>>>
>>> Need code?
>>
>> I asked you to post your code that manipulates the path. You still
>> haven't done it. Instead you showed something that obviously isn't
>> in your actual app.
>
>I **did** paste the code that is in my app. There *isn't* any code
>that manipulates a path. I've typed literal strings exactly like I
>showed in both posts including the original, and I get bdNamError. I'm
>not just assuming willy nilly that the paths are what I think they
>are, I gave a specific example that I tested.
>
>Furthermore, I just ran the *exact* same code you pasted with the
>*exact* same path. It does not work. bdNamErr.
>
>**That** is the mystery.
>
>
>
>>> It most certainly is a valid path. The colon is not a path separator
>>> it's part of the filename.
>>
>> You forgot to add: "...in the context of POSIX/BSD. HFS calls have a
>> different convention. At the intersection, for example in Quicktime,
>> extra care is required."
>
>The code I included specified POSIX. That's all the context that's
>needed.
>
>
>
>> Just because Finder special-cases colons to display them to as
>> slashes (a concession made, I believe, to early Classic adopters),
>> that doesn't mean HFS calls are happy to see mixed colons and slashes.
>>
>> Stepping into CreateMovieStorage(), I see many HFS calls,
>> ResolveAliasWithMountFlags(), PBMakeFSSpecSync(), et al. Could there
>> be some combination of HFS API that get confused when your
>> "perfectly legit" but rather unusual paths are converted variously
>> to HFS paths, Pascal strings, legacy FSSpecs, aliases, aliases
>> resolved back to FSSpecs...
>>
>> Error -37 bnNamErr is telling you: yes, there is.
>
>
>....... and *that's a bug* ..........
>
>
>I don't supply the data reference with an HFS path with a colon in it,
>I supply it with a *valid* **POSIX** path. If the function that then
>uses the data reference spazzes because it doesn't handle the POSIX
>path properly, that's not my fault. It's a bug, and that's all I was
>trying to confirm.
>
>
>
>
>
>I appreciate your replies, but I didn't leave any code out, and I
>provided absolutely nothing but valid claims and supporting evidence.
>
>
>
>
>--
>Seth Willits
>
>
>
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>QuickTime-API mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/quicktime-api/rcurrier
>%40synthetic-ap.com
>
>This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-api/email@hidden
This email sent to email@hidden
