Those Pesky Files (was: IOXperts Video 1.1.2a47 posted)

[Steve Sisak]

(changing the subject for clarity)

At 12:36 PM -0800 2/21/08, Greg Glover wrote:
>I did some detective work today. I do have a Device Keys folder 
>containing what appears to be a key file. The mystery files are in 
>addition to this and have different names, alternating alphanumerics 
>and % signs, like %BF%FF?%BF%FF%DFX%BF%FF?%A0nl.

At this point, I'm reasonably sure it's not the key files.

>I did an experiment which might help: I drop then in the trash but 
>am unable to empty trash because these files are in use; however if 
>I quit the "IOXperts Session Monitor" process using Activity 
>Monitor, the files are no longer in use and I am able to empty 
>trash. So they seem to be owned by that process. As soon as I 
>relaunch it (ioxsessiond app inside /Library/Application 
>Support/IOXperts/Private/ ) another one of these files is re-created.

This is useful information -- ioxsessiond shouldn't be creating any files.

At startup, is registers a couple mach ports for the purpose of 
receiving AppleEvents on behalf of ioxdeviced and connects to 
ioxdeviced via a pair of unix domain sockets which live in:

/var/tmp/com.ioxperts.dm.1.1.rpc.localserver
com.ioxperts.dm.notify.1.1.rpc.localserver

On my machine,

Quad:/var sgs$ ls -l /var/
[snip]
drwxrwxrwt   21 root    wheel    714 Feb 22 15:11 tmp

Quad:/var sgs$ ls -l /var/tmp
[snip]
drwxr-xr-x   3 root  wheel    102 Feb 21 11:04 
com.ioxperts.dm.1.1.rpc.localserver
drwxr-xr-x   3 root  wheel    102 Feb 21 11:04 
com.ioxperts.dm.notify.1.1.rpc.localserver
[snip]


Quad:/var sgs$ ls -l /var/tmp/com.iox*
/var/tmp/com.ioxperts.dm.1.1.rpc.localserver:
total 0
srwxrwxrwx   1 root  wheel  0 Feb 21 11:04 Socket

/var/tmp/com.ioxperts.dm.notify.1.1.rpc.localserver:
total 0
srwxrwxrwx   1 root  wheel  0 Feb 21 11:04 Socket

You might check the permissions the corresponding files/directories 
on your machine just in case something is causing a failure opening 
the sockets, etc.

Also, if you're not running a logging version of the driver, try that 
and zip up /Library/Logs/IOXperts from a failure run and I'll take a 
look at it for clues.

I'll walk through the startup code for ioxsessiond and look for any 
place a file could be created instead of a socket if something fails.

>>One interesting experiment would be to make the root directory read 
>>only and see what crashes.
>>
>
>Not sure I want to try that!

It's actually pretty safe as nothing normally creates files in /

ioxsessiond runs with normal user permissions so it wouldn't be able 
to create the files.

More later,

-Steve

-- 
_________________________________________________________________________
Steve Sisak, CTO                                 steve.sisak at ioxperts.com
IOXperts, Inc.                                     voice: +1 617 876-2572
87 Bristol St #3A                                    fax: +1 617 876-2337
Cambridge, MA 02139                               mobile: +1 617 388-6476