• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
CoreMIDI and fBsyErr
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CoreMIDI and fBsyErr


  • Subject: CoreMIDI and fBsyErr
  • From: "Cianflone, Chris" <email@hidden>
  • Date: Thu, 10 Jul 2003 01:03:55 -0500

Sending a third time... I was having problems earlier today and hoping I
will not now.

> ----------
> From: Cianflone, Chris
> Sent: Wednesday, July 9, 2003 5:24 PM
> To: 'email@hidden'
> Cc: 'email@hidden'
> Subject: CoreMIDI and fBsyErr
>
> Hi all,
>
> (Copying the Carbon-dev list too in case anyone has any insight there on
> this.)
>
> We have a CFM app (although our internal Mach-O build shows the same
> problem I am going to describe here) that is running into some fBsyErr
> errors when trying to delete some intermediate/temporary files we use
> while our application is running. This problem only occurs when I enable
> the code in our app that accesses the CoreMIDI routines. This is on 10.1.5
> an 10.2.6. (And just today one of our tech support guys told me that the
> fBsyErr was not happening under the OS X 10.3 version. Hmm...)
>
> When I encounter the fBsyErr, our app has an assert that comes up for
> testing that allows us to not treat this as a fatal error. Before
> answering that dialog, I drop into terminal and use fstat to get the
> following information:
>
> [Chris-Cianflones-Computer:501/Temporary Items/Finale Temp Files]
> ccianflo% fstat EnigmaTemp*
> USER CMD PID FD INUM MODE SZ|DV R/W MOUNT NAME
> ccianflo MIDIServer 2257 16 457487 -rw-r--r-- 4096 rw /
> EnigmaTemp3729302
> ccianflo MIDIServer 2257 17 457488 -rw-r--r-- 4096 rw /
> EnigmaTemp3729303
> ccianflo MIDIServer 2257 18 457489 -rw-r--r-- 128 rw /
> EnigmaTemp3729304
> ccianflo MIDIServer 2257 19 457490 -rw-r--r-- 512 rw /
> EnigmaTemp3729305
> ccianflo MIDIServer 2257 20 457491 -rw-r--r-- 8192 rw /
> EnigmaTemp3729306
> ccianflo MIDIServer 2257 21 457492 -rw-r--r-- 16384 rw /
> EnigmaTemp3729307
> ccianflo MIDIServer 2257 22 457493 -rw-r--r-- 132 rw /
> EnigmaTemp3729308
> ccianflo MIDIServer 2257 23 457494 -rw-r--r-- 512 rw /
> EnigmaTemp3729309
> ccianflo MIDIServer 2257 24 457495 -rw-r--r-- 512 rw /
> EnigmaTemp3729310
> ccianflo MIDIServer 2257 25 457496 -rw-r--r-- 512 rw /
> EnigmaTemp3729311
> ccianflo MIDIServer 2257 26 457497 -rw-r--r-- 144 rw /
> EnigmaTemp3729312
> ccianflo MIDIServer 2257 27 457498 -rw-r--r-- 512 rw /
> EnigmaTemp3729313
> ccianflo MIDIServer 2257 28 457499 -rw-r--r-- 128 rw /
> EnigmaTemp3729314
> ccianflo MIDIServer 2257 29 457500 -rw-r--r-- 512 rw /
> EnigmaTemp3729315
> ccianflo LaunchCFMA 2256 16 457503 -rw-r--r-- 130 rw /
> EnigmaTemp3729317
> ccianflo LaunchCFMA 2256 17 457504 -rw-r--r-- 512 rw /
> EnigmaTemp3729318
> ccianflo LaunchCFMA 2256 18 457505 -rw-r--r-- 128 rw /
> EnigmaTemp3729319
> ccianflo LaunchCFMA 2256 19 457506 -rw-r--r-- 512 rw /
> EnigmaTemp3729320
> ccianflo LaunchCFMA 2256 20 457507 -rw-r--r-- 132 rw /
> EnigmaTemp3729321
> ccianflo LaunchCFMA 2256 21 457508 -rw-r--r-- 512 rw /
> EnigmaTemp3729322
> ccianflo LaunchCFMA 2256 22 457509 -rw-r--r-- 132 rw /
> EnigmaTemp3729323
> ccianflo LaunchCFMA 2256 23 457510 -rw-r--r-- 512 rw /
> EnigmaTemp3729324
> ccianflo LaunchCFMA 2256 24 457511 -rw-r--r-- 512 rw /
> EnigmaTemp3729325
> ccianflo LaunchCFMA 2256 25 457512 -rw-r--r-- 512 rw /
> EnigmaTemp3729326
> ccianflo LaunchCFMA 2256 26 457497 -rw-r--r-- 144 rw /
> EnigmaTemp3729312
> ccianflo LaunchCFMA 2256 27 457498 -rw-r--r-- 512 rw /
> EnigmaTemp3729313
> ccianflo LaunchCFMA 2256 28 457499 -rw-r--r-- 128 rw /
> EnigmaTemp3729314
> ccianflo LaunchCFMA 2256 29 457500 -rw-r--r-- 512 rw /
> EnigmaTemp3729315
>
> Sure enough, the MIDIServer is somehow opening our temporary files. So why
> is CoreMIDI grabbing hold of our open files? Is this normal behavior?
>
> I have looked at TechNote 2037 (Exclusive File Access in Mac OS X) but I
> am not sure how to proceed. The GrabBag sample code looks promising, in
> particular, the FileAccess.c stuff. This could of course be hard to do
> since the files mentioned above are created by a third party library. We
> do have source, but I hate having to do that kind of low level
> modifications to code that is not ours. Does it matter that the third
> party library is still using the non-FSRef File Manager routines? Will
> CoreMIDI honor the lock files if I go through the trouble of doing that?
>
> Or do I basically never treat an fBsyErr as a true fatal error because
> that is "just the way Unix works". I am making that statement based upon
> information in the TN2037 and from other comments I have seen on the
> Carbon and CoreAudio development lists. I think it is more than that
> because I would suspect restarting the machine would cause all processes
> to no longer hold onto the files, and then the files should be deleted.
> But even a restart shows the files are still there. Did the MIDIServer
> somehow open the files but never close them? Did the close routines we
> were using truly fail, and thus the file was never deleted.
>
> Thanks and ANY info on this would be greatly appreciated.
>
> Chris Cianflone
> Software Engineer
> MakeMusic!, Inc.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Re: AudioDevice, sleep time after device stream changed is in need?
  • Next by Date: Atomic operations
  • Previous by thread: Re: MIDI parser
  • Next by thread: Re: CoreMIDI and fBsyErr
  • Index(es):
    • Date
    • Thread