Re: DNS resolution for apps vs Terminal?

[Michael Nickerson]

> On Jun 14, 2016, at 5:11 AM, Rick Mann  wrote:
> 
> Just now Safari stopped being able to load facbook.com. So did Chrome. Both 
> reported DNS failures.
> 
> But dig on the command line, and curl, both succeed.
> 
> How are these two domains different?
> 

Safari and other apps are using the frameworks to resolve DNS (which, I 
believe, is ultimately done via mDNSResponder, but I could be wrong on that 
one), while command line programs are using lower level calls that query the 
DNS server directly.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Networking framework crash

[Michael Nickerson]

 On Feb 4, 2015, at 9:49 PM, Graham Cox graham@bigpond.com wrote:
 On 5 Feb 2015, at 12:20 pm, Roland King r...@rols.org wrote:
 
 You should google EXC_GUARD, it’s interesting. 
 
 0x400200fe
 
 the 02 in the middle says the guard is in dup(), which it is. The 0xfe at 
 the end tells you what file descriptor it’s on. (0xfe .. really, seems 
 unusually if not impossibly large for a file descriptor, you got that many 
 files open?).
 
 
 Well, at the point where this crashes, I haven't opened any files at all 
 myself, though it partly depends what you mean by file in this context, and 
 whether the lower level code invoked by NSURLSession opens files for its own 
 use. As I said, I'm creating about 50 NSURLSessions as my app launches, which 
 may be simply too many.
 
 I am googling EXC_GUARD but haven't found anything that breaks it down - just 
 a bunch of people asking what it is.

Everything is a file descriptor. Open files, sockets, loaded frameworks  
bundles, even STDIN/OUT/ERROR.

You can check if you're hitting the limit of file descriptors by (temporarily) 
raising the number you can have open with setrlimit(). If you raise it and your 
app stops crashing, then that's likely the culprit. I would guess so - the 
default max number you can have open is 256, and 0xfe lines up with that...

If your app runs long enough before crashing, you can also use lsof in Terminal 
to see what your app has open.




Michael Nickerson
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Networking framework crash

[Michael Nickerson]

 On Feb 5, 2015, at 10:22 AM, Roland King r...@rols.org wrote:
 
 
 
 Everything is a file descriptor. Open files, sockets, loaded frameworks  
 bundles, even STDIN/OUT/ERROR.
 
 You can check if you're hitting the limit of file descriptors by 
 (temporarily) raising the number you can have open with setrlimit(). If you 
 raise it and your app stops crashing, then that's likely the culprit. I 
 would guess so - the default max number you can have open is 256, and 0xfe 
 lines up with that...
 
 If your app runs long enough before crashing, you can also use lsof in 
 Terminal to see what your app has open.
 
 
 Where do you get 256 from? I just inserted the following two lines of code 
 into a random OSX GUI app and a command line tool I wrote, right after launch
 
   struct rlimit file_limit;
   getrlimit( RLIMIT_NOFILE, file_limit );
 
 For the GUI app I get
 
   file_limit.rlim_cur = 9472
 
 and for the command line I get
 
   file_limit.rlim_cur = 7168
 
 when run from Xcode or 2560 in either case when run from the command line or 
 double-clicked from the finder. 
 

Well, that'll teach me to double check before posting. I hadn't realized the 
max got upped. Seems like it's 2560 (I would guess it's higher when run in 
Xcode for debugging).


 all of which seems to indicate processes have plenty more than 256 file 
 descriptors available by default. I thought 256 was left behind as a default 
 long ago because it was way too small. 
 

Makes sense to me. I have run up against the max open files limit before when 
it was still 256. I am happy to see it was raised.


 launchctl limit shows 
 
 maxfiles256unlimited   
 
 That’s the only place I can find 256 and I don’t know when that is used.
 

So, I take the above back - not running into the limit, unless maybe it's being 
run by launchd. Those limits shown by launchctl are what's used by anything 
launchd launches, unless the plist file overrides them. I wonder if that's on 
purpose or just an oversight?


And yes, I tested that this time! I get:

Feb  5 11:16:46.875 test[4252]: cur: 2560
Feb  5 11:18:00.078 test[4274]: cur: 256

(First is normal run, second is launched by launchd.)



Michael Nickerson



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Preferences caching?

[Michael Nickerson]

 On Nov 28, 2013, at 5:27 AM, Graham Cox graham@bigpond.com wrote:
 On 28 Nov 2013, at 1:14 am, Shane Stanley sstan...@myriad-com.com.au wrote:
 
 Or write a one-line AppleScript script:
 
 do shell script defaults delete ...
 
 Save it as a code-signed app, send it to them, and tell them to 
 double-click. A lot easier than navigating Library folders for the average 
 user.
 
 Good idea. I’ll make sure we have these available if such a support issue 
 ever comes up. Thanks for the suggestion.

As an alternative, you could test for some key combo held down on launch, like 
iPhoto or iTunes does to allow one to pick a different library to load from. 
See the key combo at launch time, and you can go down a different code path 
that doesn't access the preferences at all and resets/deletes them, then 
continue on to normal launch after that.

_
Michael Nickerson

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing. WTF?

[Michael Nickerson]

On May 28, 2012, at 5:51 AM, Graham Cox graham@bigpond.com wrote:

 
 On 28/05/2012, at 7:31 PM, Roland King wrote:
 
 The way I read it is you register the entitlement exactly as you have been 
 doing, as a user entitlement to Library/whatever. Then at runtime you use 
 getpwuid() to find an absolute path to the actual user's home directory, 
 construct the Library/whatever on top of that as an absolute (and of 
 course dynamic depending on the user) path and open the file there. If my 
 understanding is correct, the generic user entitlement you added will give 
 you access to th
 
 That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, 
 just a bundle ID and key. I can't see an alternative API that takes a path - 
 are you saying I have to open the file and parse it myself? While that isn't 
 too hard, it seems to be going against the point of having an API for 
 preferences which isolate you from format changes and file system details and 
 so on.
 
 --Graham
 
 
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/darkshadow02%40mac.com
 
 This email sent to darkshado...@mac.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing. WTF?

[Michael Nickerson]

On May 28, 2012, at 5:51 AM, Graham Cox graham@bigpond.com wrote:

 
 That sounds fine, except that CFPreferencesCopyAppValue doesn't take a path, 
 just a bundle ID and key. I can't see an alternative API that takes a path - 
 are you saying I have to open the file and parse it myself? While that isn't 
 too hard, it seems to be going against the point of having an API for 
 preferences which isolate you from format changes and file system details and 
 so on.
 
 --Graham
 
 
 

The CFPreferences... calls will actually take a path. Just give it the path 
where the bundle ID should go. This is not documented anywhere, but it works.

If you'd rather not count on that always working, you don't have to parse the 
plist yourself, just read the plist in as data and use 
NSPropertyListSerialization (or CFPropertyList, if you need the CF calls for 
some reason) to parse it.


(Sorry if a blank email also got sent; I fat-fingered something while selecting 
text on my iPad and am not sure if it sent or was canceled.)


--

Michael Nickerson
http://www.nightproductions.net
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSLayoutManager's setDefaultAttachmentScaling: not working in custom PDF NSContexts.

[Michael Nickerson]

On Jan 29, 2012, at 1:03 PM, Gus Mueller wrote:

 I have an issue where using NSLayoutManager's 
 setDefaultAttachmentScaling:NSImageScaleProportionallyDown doesn't seem to 
 work if I setup my own NSGraphicsContext + CGPDFContext.
 
 The problem is that large inline images are not scaled down when drawn like 
 they would be in an NSTextView.  Text after the image is positioned as if it 
 was scaled though, so I end up with text that is drawn over an image.
 
 
 Can anyone shed some light on what I'm doing wrong?
 This is on 10.7.2 btw.
 


Hmm, I don't have an answer for you, but I looked at the code.  I did a little 
subclassing of NSLayoutManager, and it looks like the text attachment cell is 
just ignoring the size given to draw the image in and drawing it full size.

Here's what I used:

@interface DSLayoutManager : NSLayoutManager {
}
@end

@implementation DSLayoutManager

- (void)showAttachmentCell:(NSCell *)cell inRect:(NSRect)rect 
characterIndex:(NSUInteger)attachmentIndex
{
[super showAttachmentCell:cell inRect:rect characterIndex:attachmentIndex];
[NSGraphicsContext saveGraphicsState];
CGContextTranslateCTM([[NSGraphicsContext currentContext] graphicsPort], 0, 
-rect.size.height);
[[NSColor blackColor] set];
[NSBezierPath strokeRect:rect];
[NSGraphicsContext restoreGraphicsState];

}

@end


Add that to the top, and change the layout manager to use it, and it'll draw 
the rect the layout manager is telling the attachment cell to draw in.

Maybe there's some sort of context related setting that's different between the 
text view and the PDF context?


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: music.read-only sandbox entitlement doesn't seem to work

[Michael Nickerson]

On Jan 09, 2012, at 12:52 PM, Michael Crawford wrote:

 I'm converting over a legacy Core-Audio application to run sandboxed.  This 
 app normally access files in the iTunes library in order to analyze them for 
 BPM information.  Enabling the music.read-only entitlement does not work.
 
   com.apple.security.assets.music.read-only
 
 I get the following error:
 
   deny file-read-data /Users/smj/Music/iTunes/iTunes Music/Depeche 
 Mode/Violator/01 World In My Eyes.mp3
 
 I have been able to overcome this problem by adding the temporary exception 
 to perform relative reads from the users home directory using this path:
 
   /Music/iTunes/iTunes Music/
 


I don't have a solution for you, but I wanted to point out that even using 
temporary exceptions won't work for everyone - you can change iTune's music 
library to some other path within iTunes.

 
--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Debugging a sleepless Mac

[Michael Nickerson]

On Mar 16, 2011, at 8:37 AM, Matt Gough wrote:

 I've just been adding code to support NSWorkspaceWillSleepNotification. 
 Having lowered my Computer sleep time right down and left the Mac untouched 
 for several minutes, my code never fires and the Mac doesn't actually go to 
 sleep. Even without my app running and leaving the Mac for several hours I 
 notice that it still won't sleep.
 
 So it seems that something else is preventing idle sleep, but I've no idea 
 how to find the culprit. Is there some defaults setting I can use that will 
 log what the OS wants to do at sleep time and what is blocking it?
 
 

I don't know of a way to log what might be blocking it, but I ran some tests a 
while back that showed the system has to be idle for 10 minutes before it will 
sleep.  Or, at least the disk has to be idle for 10 minutes, otherwise sleep is 
deferred.  I ran into this with one of my applications that is long running.  
It (can) access the disk frequently to open and read files.  It turned out that 
was causing my Mac not to sleep - definitely not something I wanted to happen.

What I ended up doing was writing a method that fires via a timer every minute, 
and checks the sleep time - if I'm within 10 minutes of it, I stop my 
application from reading anymore.  This stopped the problem, so far as my own 
application was concerned, though as others have pointed out there's plenty of 
other things that can keep the system from sleeping that you might not have 
control of.

So, here's a short version of the code I'm using to do this (typed in Mail):

#import IOKit/pwr_mgt/IOPMLib.h
#import IOKit/pwr_mgt/IOPM.h

- (void)checkIdleTime:(NSTimer *)timer
{
unsigned long mins = 0, systemIdleMinutes = 0;
CFTimeInterval idleSeconds = CGEventSourceSecondsSinceLastEventType( 
kCGEventSourceStateCombinedSessionState, kCGAnyInputEventType );
static CFTimeInterval lastSeconds = 0.0;

systemIdleMinutes = lrint(idleSeconds / 60.0); /* Gives minutes of 
inactivity */

if ( lastSeconds  idleSeconds ) {
/* User activity has occurred since last check, if you disabled 
anything you can re-enable it here. */
}

lastSeconds = idleSeconds;

/* No need to check this if the system isn't idle. */
if ( systemIdleMinutes ) {
mach_port_t master_device_port;
io_connect_t fb = 0;
kern_return_t kr = kIOReturnSuccess;
IOReturn err = kIOReturnSuccess;

kr = IOMasterPort( bootstrap_port, master_device_port );
if ( kr == kIOReturnSuccess ) {
fb = IOPMFindPowerManagement( master_device_port );
if ( fb ) {
err = IOPMGetAggressiveness( fb, kPMMinutesToSleep, mins );
if ( (err == kIOReturnSuccess)  (mins  0)  ((mins - 
systemIdleMinutes) = 10) ) {
/* Do whatever you want to notify your app it should stop 
disk access here */
}
/* If you want to find out how long until the screen dims, you 
can do the same as above but use kPMMinutesToDim instead. */
IOServiceClose( fb );
}
}
}
}


Do note one limitation of this as is: if the system is set to sleep in 10 
minutes or less, it will fire the condition as soon as the timer is hit and 
there has been no user activity for at least a minute.  This is something I've 
been meaning to look into but haven't as yet.


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Alternative startup for application

[Michael Nickerson]

On Apr 02, 2010, at 10:12 PM, Gideon King wrote:

 That's the instance method. New in 10.6 is the class method of the same name, 
 which is what I need in this case, since I don't have an event to work with.
 
 On 03/04/2010, at 12:09 PM, Klaus Backert wrote:
 
 
 On 3 Apr 2010, at 01:15, Gideon King wrote:
 
 Excellent, I like the new way of doing it using NSEvent directly, but I do 
 need to support Leopard.
 
 - (NSUInteger)modifierFlags
 
 Available in Mac OS X v10.0 and later.
 
 


You can use CGEventSourceKeyState( kCGEventSourceStateCombinedSessionState, 
0x3A ).  That function will get the key down state at the time of the call, and 
0x3A is the key code for the option key.


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sending launch and quit Apple Events: Crazy Connection Errors

[Michael Nickerson]

On Jul 7, 2009, at 8:21 AM, Jerry Krinock wrote:

I need to be able to quit and re-launch other applications, and have  
been getting all kinds of weird behavior.  Maybe if someone could  
explain this one little test case I've isolated, it would be a big  
help.


The code below attempts to launch TextEdit, wait 5 seconds, quit  
TextEdit, wait 5 seconds, repeat forever.  I get a launch, a quit,  
and a launch.  But when it tries to quit for the second time,  
AESendMessage returns a -609 Connection Invalid error.  I imagine  
this is because it is trying to connect to the application instance  
that it had quit the first time.


Documention of AESendMessage implies that recent versions of  
AppleScript will automatically try and reconnect, and that there is  
no more option to set.


How can I get it to forget the old connection and make a new one?

Thanks,

Jerry




I added similar functionality to one of my apps, and had problems  
using the bundle id as well.  I switched to using the PSN  
(typeProcessSerialNumber) and that seems to work.  You can use this to  
get the PSN:


void PSNForBundleIdentifier( NSString *bundleIdentifier,  
ProcessSerialNumber *psn )

{
OSStatus anErr = noErr;
ProcessSerialNumber aNum = { kNoProcess, kNoProcess };

if ( psn == NULL ) return;

while ( (anErr == noErr) ) {
anErr = GetNextProcess( aNum );
if ( anErr == noErr ) {
CFDictionaryRef procInfo =  
ProcessInformationCopyDictionary( aNum,  
kProcessDictionaryIncludeAllInformationMask );
if ( [[(NSDictionary *)procInfo objectForKey:(NSString  
*)kCFBundleIdentifierKey] isEqualToString:bundleIdentifier] ) {

*psn = aNum;
CFRelease( procInfo );
break;
}
CFRelease( procInfo );
}
}
}


And then change your QuitAndSleep function to:

void QuitAndSleep(NSString* bundleIdentifier, float seconds) {
   NSLog(@Quitting) ;
   NSAppleEventDescriptor *as ;
   ProcessSerialNumber aNum = { kNoProcess, kNoProcess } ;

   PSNForBundleIdentifier( bundleIdentifier, aNum );

   as = [NSAppleEventDescriptor  
descriptorWithDescriptorType:typeProcessSerialNumber

   bytes:aNum
   
length:sizeof(aNum)];

   NSAppleEventDescriptor *ae ;
   ae = [NSAppleEventDescriptor  
appleEventWithEventClass:kCoreEventClass
  
eventID:kAEQuitApplication

targetDescriptor:as
 
returnID:kAutoGenerateReturnID

transactionID:kAnyTransactionID];

   AppleEvent *quitApplicationAppleEventPtr = (AEDesc*)[ae aeDesc];
   if (quitApplicationAppleEventPtr) {
   OSStatus err = AESendMessage(quitApplicationAppleEventPtr,
NULL,
kAENoReply,
kAEDefaultTimeout) ;
   NSLog(@Quit err = %d, err) ;
   }
   NSLog(@Sleep after quit) ;
   usleep(seconds * 1e6) ;

}


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: How do I include a URL in a preprocessed Info.plist?

[Michael Nickerson]

On Dec 27, 2008, at 7:37 PM, Graham Cox wrote:



Anyway, that's useful info, at least it explains what I'm seeing. I  
worked around it in a different way in the end - I added a user- 
defined setting for my URL then just used ${MY_URL} in the plist.  
That worked fine - this is similar to Phillipe's suggestion.




I know you found a way to do this that works for you, but I just  
wanted to point out that you can also just put it into the  
InfoPlist.strings file(s) and it'll work just fine (and, in the case  
of Sparkle, allows you to have different URLs for different  
localizations if you want to do that).


Just so I'm clear here, I mean putting the key into the  
InfoPlist.strings file(s) rather than into the Info.plist file.  This  
will work for almost any key you want to use, as long as you (or the  
underlying API) is using -objectForInfoDictionaryKey to look up the  
keys.


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Security - Write to protected directory

[Michael Nickerson]

On Oct 27, 2008, at 12:52 AM, Michael Ash wrote:


On Mon, Oct 27, 2008 at 12:07 AM, Michael Nickerson
[EMAIL PROTECTED] wrote:


You can always set things up to ignore child processes:
signal( SIGCHLD, SIG_IGN );


It's bad to rely on this sort of global state, though. What if some
other bit of code relies on having a handler for this signal? (Of
course it is relying on this sort of global state too in that case,
but it takes two to screw things up)



Libraries and frameworks shouldn't be setting or relying on signals.   
It is, as you say, a global state.  So really, if you haven't  
specifically set it in your app, you should be fine and if you have  
you should already know about it.


That way, if the children aren't specifically reaped they don't  
stay around
as zombies.  Do note that the wait functions *do* still work if you  
set that
up, so this isn't going to mess anything up elsewhere that is  
reaping a

child.


How does that work, exactly? The whole purpose of the zombie is to
store the end state of the dead process so that wait() can pick it up.
If wait() still works, then what stores that end state if not a zombie
process? More to the point, if wait() still works, that implies that
*something*, *somewhere* is storing that end state. And if you never
call wait() but you continue to create children, that storage will
grow without limit, and this is bad. So it seems to me that either no,
wait() doesn't really work in this scenario, or in fact you still get
zombies or something like them. Am I missing something?



Sorry, my fault for replying late at night.  The wait functions will  
still block for the duration of the child process, but you do lose the  
state information about it.  So if you're relying on state information  
I suppose you would consider that broken, but if all you're using wait  
for is to wait until the child process has terminated, then it still  
works as intended.


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Security - Write to protected directory

[Michael Nickerson]

On Oct 24, 2008, at 10:46 PM, Michael Ash wrote:


On Fri, Oct 24, 2008 at 8:46 PM, Tommy Nordgren
[EMAIL PROTECTED] wrote:


On 3 okt 2008, at 16.39, Michael Ash wrote:


...snip



Nope! AEWP is a rather broken API in more ways than one. One of the
ways that it's broken is that it is *impossible* to correctly use it
without a subprocess which will cooperate with you. The reason for
this is that you *must* use wait4 or waitpid to reap the zombie that
will be created when the subprocess terminates, but AEWP provides  
*no*
way to get the pid. (You cannot use wait or wait3 because those  
could


  NOPE. As soon as the App terminates, any unreaped subprocess  
will

become a child
of, and finally reaped by launchd


That's true, except it's bad form to leave zombies lying around when
your application has an unbounded lifetime, as basically every GUI
application does. It goes from bad to extremely bad if the
authorization process can be repeated an arbitrary number of times,
since you can build up an unlimited number of zombies that way. The
extreme difficulty of reaping the children left behind by AEWP is a
huge deficiency in the API.



You can always set things up to ignore child processes:
signal( SIGCHLD, SIG_IGN );

That way, if the children aren't specifically reaped they don't stay  
around as zombies.  Do note that the wait functions *do* still work if  
you set that up, so this isn't going to mess anything up elsewhere  
that is reaping a child.



--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: showing window causes EXC_BAD_ACCESS

[Michael Nickerson]

On Sep 27, 2008, at 4:44 PM, Uli Kusterer wrote:



That said, I fully agree on one partial point you raised: 'Release  
when closed' is dangerous and complicates matters. It should be off  
by default, and it's very likely that nobody would miss it. That  
said, I don't know what it was originally introduced for. Any old  
NeXTies here who know?




Well, I'm not an old NeXTie, but I use this when I make a throw away  
window programmatically.  Something like the About panel, say.   
Instead of setting up a delegate and have it autorelease the window on  
the -windowShouldClose: method, I just set it up with release when  
closed and I know when the window is closed it gets released.


I have no idea why it's an option in a nib file, though.  Perhaps  
someone just wanted to be thorough in giving you the window's options?


Does the window really get deallocated when using this option?  I  
haven't really looked, but wouldn't the nib's owner still have a  
reference to it as part of its top level objects?




--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: CFBundleIconFile: heiß or hot?

[Michael Nickerson]

On Aug 28, 2008, at 2:15 AM, Gerriet M. Denkmann wrote:



//  this always works, regardless of name:
- (IBAction)ImageNameD: sender;
{
NSBundle *mainBundle = [ NSBundle mainBundle ];
NSDictionary *infoDictionary = [ mainBundle infoDictionary ];
	NSString *iconFile = [ infoDictionary objectForKey:  
@CFBundleIconFile ];	

NSImage *image = [ NSImage imageNamed: iconFile ];
[ imageView setImage: image ];
}



You can make that shorter, by removing the infoDictionary ivar and  
changing the iconFile one to [mainBundle  
objectForInfoDictionaryKey:@CFBundleIconFile].


Could someone please show me, where the valid values for  
CFBundleIconFile are documented?

Tiger 10.4.11.



Property List Key Reference:
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-BCIJIJBH 




--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

10.5 and root proxies

[Michael Nickerson]

Hey all,

I'm running into a strange problem with root proxies in 10.5.  I have  
been tracking down memory leaks in my app, and it seems that  
+rootProxyForConnectionWithRegisteredName:host: has been changed in  
10.5 to return the root proxy retained rather than autoreleased.  I  
haven't seen anything in the docs to reflect this, but testing seems  
to prove it.  I did run across this curious mention in the Foundation  
release notes, though it doesn't really state things one way or the  
other:


Leaks in Distributed Objects plugged

Some leaks, and places where objects could leak if the timing was  
right, in Distributed Objects have been fixed in 10.5. This may mean  
that you may no longer get away with something you used to get away  
with due to the leak. Not retaining the root proxy you get from the  
connection, if you're going to hold onto it, seems to be a common  
pitfall.



Can anyone confirm this, or see anything wrong with the code below  
that might lead to this?


Here's a simplified version of the code I'm actually using (not the  
entire class, just basic portions of it):



- (id)init
{
   if ( (self = [super init]) ) {
   NSUInteger numTries = 0;
   struct timespec tv = { 0, 25000 }; /* .25 of a second */

   [NSThread detachNewThreadSelector:@selector(backgroundThread:)  
toTarget:self withObject:nil];


   while ( (threadPortName == nil)  (numTries  20) ) {
   nanosleep( tv, NULL );
   numTries += 1;
   }

   /* threadPortName and threadProxy are class ivars */

   if ( threadPortName != nil ) {
   threadProxy = [NSConnection  
rootProxyForConnectionWithRegisteredName:threadPortName host:nil];

   /* Causes threadProxy to never be released under 10.5
  when uncommented; crash under 10.4 when commented
   */
   //[threadProxy retain];
   }

   if ( threadProxy == nil ) {
[self autorelease];
   return nil;
   }
   }

   return self;
}

/* Always called when the class's task is done */
- (void)releaseBackgroundThread
{
   if ( threadProxy != nil ) {
   [threadProxy stopThread];
   [threadProxy autorelease];
   threadProxy = nil;
   }
}

/* Called on thread */
- (void)stopThread
{
   stopThread = YES;
}

- (void)backgroundThread:(id)sender
{
   NSAutoreleasePool *threadPool = [[NSAutoreleasePool alloc] init];
   CFUUIDRef uuid = CFUUIDCreate( NULL );
   NSString *threadName = (NSString *)CFUUIDCreateString( NULL, uuid );
   NSConnection *myCon = [[NSConnection defaultConnection] retain];
   NSRunLoop *current = [NSRunLoop currentRunLoop];

   CFRelease( uuid );

   [myCon setRootObject:self];

   if ( ![myCon registerName:threadName] ) {
   [threadName release];
   [threadPool release];
   return;
   }

   threadPortName = threadName;

   while ( !stopThread ) {
   NSAutoreleasePool *runPool = [[NSAutoreleasePool alloc] init];
   [current runUntilDate:[NSDate dateWithTimeIntervalSinceNow:2.]];
   [runPool release];
   }

   [myCon invalidate];
   [myCon release];
   [threadPool release];
}


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Can't get file type code using [fileAttr valueForKey:NSFileHFSTypeCode]

[Michael Nickerson]

On May 23, 2008, at 5:19 PM, Sean McBride wrote:


On 5/22/08 4:37 PM, Lynn Barton said:

From what I have read quickly since Sean McBride sent his comment,  
UTIs are
not yet implemented to the point where I could get the UTI of every  
file on

my computer.


Sure you can.  Use LSCopyItemAttributes() with kLSItemContentType.



I've written a category on NSFileManager that, among other things,  
will do this.  Here's the relevant portion for you:


__
#import Foundation/Foundation.h

@interface NSFileManager (DSFileAdditions)
+ (NSString *)UTIForFile:(NSString *)path;
+ (NSString *)UTIForURL:(NSURL *)url;
@end

@implementation NSFileManager (DSFileAdditions)

+ (NSString *)UTIForFile:(NSString *)path
{
return [self UTIForURL:[NSURL fileURLWithPath:path]];
}

+ (NSString *)UTIForURL:(NSURL *)url
{
NSString *retval = nil;
FSRefPtr fileRef = NULL;

fileRef = calloc( 1, sizeof( FSRef ) );

	if ( (fileRef != NULL)  (url != nil)  [url isFileURL]   
(CFURLGetFSRef( (CFURLRef)url, fileRef ) == true) ) {

CFStringRef theUTI = NULL;
		if ( LSCopyItemAttribute( fileRef, kLSRolesAll, kLSItemContentType,  
(CFTypeRef *)theUTI ) == noErr ) {

retval = [[(NSString *)theUTI copy] autorelease];
CFRelease( theUTI );
}
}

if ( fileRef != NULL )
free( fileRef );

return retval;
}
__


I *think* this code should work fine under GC (for anyone using it),  
but you should probably test it first as I haven't.



--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Saving only required files in a file wrapper?

[Michael Nickerson]

On May 8, 2008, at 7:30 AM, Keith Blount wrote:

Apologies for so soon a follow up, but I've just been experimenting  
with -writeToURL:ofType:forSaveOperation:originalContentsURL:error:  
and the results are disastrous. It turns out that *every single  
time* it is invoked, absoluteURL is a temporary location and *not*  
the original URL. So to use this method successfully I would need to  
copy the whole file package across to that location every time,  
which is exactly what I _don't_ want to do. This seems a little  
insane to me. There must be a mechanism in place that just lets you  
save into a package folder without having to write the whole thing  
out every time...


Thanks again and all the best,
Keith



I went through some of this recently - I'm using a helper tool to  
actually save the files, and I had to figure some of this out to get  
that working right.


absoluteURL is going to always be a temp location because that's how  
the document system works - it writes to the temp location, then  
overwrites the original location if that's successful.  Keeps file  
corruption to a minimum.


absoluteOriginalContentsURL should probably be the original URL.  The  
only time it's not likely to be the original path (what's returned by  
[self fileURL]) is if the user has moved / renamed the original file  
in between when it was opened and when it's being saved.  (I'm fairly  
certain this is why you're told not to use -fileURL when writing -  
because that's not updated if the user moves / renames the file while  
it's being edited.)


If you don't want to rely on that, there's nothing stopping you from  
creating a new ivar to save the URL passed in when you read the file.   
Though that can break if the user moves / renames the file while it's  
being edited.  I know, not likely, but you can't be 100% certain on  
that.  If you'd like to do this, but want to be certain, you could get  
the original path when you read and convert it to a file alias, then  
resolve the alias when you're writing - then you're guaranteed to have  
the correct path (this is what I actually decided to do).  The only  
way that would break is if the user moves the file to a different hard  
drive, and I believe the normal NSDocument methods wouldn't work  
correctly in that case anyway (I believe the user gets shown a dialog  
saying the original file couldn't be found).


Once you have the original path (whichever way you choose to get it),  
you can do what you were before to save the files in the wrapper.  Or,  
if you want to, you can save it to the temp location, and then  
overwrite the individual files yourself using NSFileManager.  Though  
if you do that, *make sure to delete the temp file* before returning  
(if you use the same path as absoluteURL for the temp file, anyway).   
If you don't, the document system will copy it over anyway and you'll  
wind up with your original problem. I had an interesting time figuring  
that last part out.  In my case, the original files aren't actually  
writable by anyone but root, and it would fail when it tried to copy  
the temp files over the original files (even though my helper tool had  
actually already done that).  Made for an interesting case where the  
file was actually saved but the app didn't think so.


Hope that helps out some.


--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Rotating an NSTableView.

[Michael Nickerson]

On May 1, 2008, at 8:27 AM, Peter Hudson wrote:

I have an NSTable View inside an NSSplitView.
I rotate the table view by sending   rotateByAngle:270  to the  
enclosing scroll view.

The table lands up exactly as I want it with vertical rows.





The problem is that when I resize the split view the NSTableView  
does not change size to fit the split view movement as it does when  
the table is not rotated.


Does anyone have any idea what is going on.  I've tried all the  
usual games with setting frame and bounds etc - but to no avail.



It looks like there's a bug in NSScrollView, where it stops calling - 
tile when it's rotated.


You can work around the problem by listening to the scroll view's  
frame change notifications, and calling -tile on it manually.



I submitted a bug against this with source code to demonstrate the  
problem: rdar://5908380



Corbin - there's also a bug where the table headers aren't drawn  
correctly when it's rotated.  I didn't submit a bug on that one - let  
me know if you'd like me to.  It'd take just a quick edit of the  
sample code I did above to have the table headers showing.



--
Darkshadow
(aka Michael Nickerson)
http://www.nightproductions.net


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]