On Wed, Jun 3, 2009 at 12:41 AM, Ken Thomases wrote:
> On Jun 2, 2009, at 9:21 PM, Michael Ash wrote:
>
>> The NSString methods are unlikely to be problematic here. NSData is
>> troublesome because it's returning an internal pointer. In other
>> words, it's a pointer to some memory that it already
On 6/2/09 10:17 PM, Michael Ash said:
>>>The description of [NSString UTF8String] says
>>>that "the returned C string is automatically freed just as a returned
>>>object would be released", which implies (to me) that the returned
>>>pointer is to GC-controlled memory.
>>
>> Then shouldn't its retu
On Jun 2, 2009, at 9:21 PM, Michael Ash wrote:
The NSString methods are unlikely to be problematic here. NSData is
troublesome because it's returning an internal pointer. In other
words, it's a pointer to some memory that it already holds on to in
the normal course of things, and it gives you th
On Tue, Jun 2, 2009 at 7:28 PM, Greg Guerin wrote:
> Quincey Morris wrote:
>
>> For completeness, I just want to add (after a bit of discussion off- list)
>> that it remains unclear whether the pointer returned by 'UTF8String' or
>> 'fileSystemRepresentation' is to be regarded as an interior point
On Tue, Jun 2, 2009 at 2:09 PM, Sean McBride wrote:
> On 6/1/09 9:31 PM, Quincey Morris said:
>
>>The description of [NSString UTF8String] says
>>that "the returned C string is automatically freed just as a returned
>>object would be released", which implies (to me) that the returned
>>pointer is
Quincey Morris wrote:
For completeness, I just want to add (after a bit of discussion
off- list) that it remains unclear whether the pointer returned by
'UTF8String' or 'fileSystemRepresentation' is to be regarded as an
interior pointer or not. (My guess is "not".)
So I submitted feedback
On Jun 2, 2009, at 08:05, Shawn Erickson wrote:
For those that don't know about the interior pointer edge case...
http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#/
/apple_ref/doc/uid/TP40008006-SW7
For completeness, I just want to add (after
On 6/1/09 9:31 PM, Quincey Morris said:
>First, I believe Sean is wrong about (b), although the documentation
>is a little unclear.
I would love to be wrong, of course.
>The description of [NSString UTF8String] says
>that "the returned C string is automatically freed just as a returned
>object w
For those that don't know about the interior pointer edge case...
http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcUsing.html#//apple_ref/doc/uid/TP40008006-SW7
-Shawn
___
Cocoa-dev mailing list (Cocoa-dev@lists.ap
On Mon, Jun 1, 2009 at 6:40 PM, Sean McBride wrote:
> But it's not a huge issue: fileSystemRepresentation and UTF8String give
> the same thing 99% of the time.
And more importantly, the 1% of the time where they give you different
results, they still give you *equivalent* results.
-fileSystemRepr
On Jun 1, 2009, at 14:53, Gwynne Raskind wrote:
On Jun 1, 2009, at 4:31 PM, Sean McBride wrote:
This is a nice trick, I wasn't aware of that function, thanks.
Perhaps a minor improvement (one call instead of two):
- (BOOL) isTrashedFileAtPath:(NSString*)path
{
Boolean inTrash = false;
On 6/1/09 3:03 PM, Martin Wierschin said:
>>> const UInt8* utfPath = (UInt8*)[path UTF8String];
>>> OSStatus err = DetermineIfPathIsEnclosedByFolder
>>> (kOnAppropriateDisk, kTrashFolderType, utfPath, false, &inTrash);
>>
>> For the archives: 2 more problems:
>>
>> a) use fileSystemRepresentation
const UInt8* utfPath = (UInt8*)[path UTF8String];
OSStatus err = DetermineIfPathIsEnclosedByFolder
(kOnAppropriateDisk, kTrashFolderType, utfPath, false, &inTrash);
For the archives: 2 more problems:
a) use fileSystemRepresentation not UTF8String.
I initially considered that, but the documen
On Jun 1, 2009, at 4:31 PM, Sean McBride wrote:
This is a nice trick, I wasn't aware of that function, thanks.
Perhaps a minor improvement (one call instead of two):
- (BOOL) isTrashedFileAtPath:(NSString*)path
{
Boolean inTrash = false;
const UInt8* utfPath = (UInt8*)[path UTF8S
On 5/28/09 3:49 PM, Martin Wierschin said:
>This is a nice trick, I wasn't aware of that function, thanks.
>Perhaps a minor improvement (one call instead of two):
>
>- (BOOL) isTrashedFileAtPath:(NSString*)path
>{
> Boolean inTrash = false;
> const UInt8* utfPath = (UInt8*)[path UTF8St
BOOL isInTrash(NSString* path) {
FSRef fsRef;
Boolean result = false ;
OSStatus err = FSPathMakeRef(
(UInt8*)[path UTF8String],
&fsRef,
NULL) ;
if (err == noErr) {
FolderType
Jerry Krinock (je...@ieee.org) on 2009-05-27 1:04 AM said:
>At first I thought these FS functions were in Carbon, but the docs say
>that they are in CoreServices, so I guess this is OK for the 64-bit
>future.
It's another example of 'Carbon' being a term with many meanings. These
APIs have their
On Wed, May 27, 2009 at 10:04 PM, Jerry Krinock wrote:
> At first I thought these FS functions were in Carbon, but the docs say that
> they are in CoreServices, so I guess this is OK for the 64-bit future.
The only parts of Carbon that are deprecated are the GUI aspects.
While it makes sense to a
Thanks, Kiel and Adam. FSDetermineIfRefIsEnclosedByFolder() has the
advantage over IdentifyFolder(parent) of working for items that are
buried in folders that are in the trash, but strangely it gives a -35
nsvErr "no such volume" error if the item is not in the trash. I just
ignore all th
On May 27, 2009, at 8:05 PM, Jerry Krinock wrote:
How can I determine if a given file path, or a file alias (I have
both), refers to an item which is in the Trash?
The obvious answer, using -[NSString hasPrefix:] on the path with
NSHomeDirectory()/.Trash, doesn't look very pretty.
Check t
Nothing comes to mind from the top of my head.
A little digging through Carbon documentation suggested you could use
FSCatalogInfo() function to determine the parent directory ID of the
file you are testing. With the result of that function, you can use
the IdentifyFolder() function to see
How can I determine if a given file path, or a file alias (I have
both), refers to an item which is in the Trash?
The obvious answer, using -[NSString hasPrefix:] on the path with
NSHomeDirectory()/.Trash, doesn't look very pretty.
Thanks,
Jerry
22 matches
Mail list logo
