Issue 1004810: Carbon.File fails if server vol is mounted after launch (original) (raw)

Issue1004810

Created on 2004-08-06 18:51 by pharr, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg60546 - (view)	Author: Paul Pharr (pharr)	Date: 2004-08-06 18:51
On MacOs X 10.3.x (with the stock Python 2.3). Carbon.File.FSSpec(theFile) will fail with a -120 (Directory Not Found) error if theFile is on a server volume which was mounted after the script was launched. In actuality, it may be a little more complex, because if there is only a single server volume mounted, then Carbon.File sometimes will not fail until the volume is mounted, unmounted, and remounted a few times. Mounting two or more volumes causes the situation to become more consistently reproducible. What is going on is that each application's instance of the Carbon File Manager depends on being notified by the MacOS X operating system when volumes are mounted and unmounted through the application's runloop. Since python scripts do not implement a runloop, the running python process' carbon file manager never gets a chance to see these notifications and consequently it's internal data structures describing the state of the mounted volumes become out of date if volumes are mounted or unmounted repeatedly from other processes. This causes most Carbon.File calls to fail when manipulating files on a server volume if that volume is mounted while the script is running. My situation is an automated build script which wants to continue running while mounting and unmounting server volumes onto which to copy the resulting build products. After the first two builds (and mounting and unmounting two AFP volumes twice), all Carbon.File calls subsequently will fail until the python script is relaunched. It seems like there would be a way to get Carbon.File to be able to look a little harder for these volumes, but I haven't found a good workaround other than to call a sub-script for any operation which requires Carbon.File.
msg60547 - (view)	Author: Jack Jansen (jackjansen) *	Date: 2004-08-14 20:03
Logged In: YES user_id=45365 Paul, I've always known that there were potential problems with some of the FSSpec calls when you have no runloop, but you're the first one (in about 10 years:-) to actually give the impression you understand what goes on. While I don't think I can fix this in Python itself (adding a runloop is hardly an option) I could document what a user would have to do, and/or provide a helper method that would execute that code or something, but I would first need to know what it is you actually have to do in the runloop. Do you happen to know this? And/or do you have references to the specific sections of Apple documentation where this is described? BTW: does the problem alson happen if you go from filename to FSRef to FSSpec? And at which stage (fsr=FSRef(filename) or fss=FSSpec(fsr))?
msg84703 - (view)	Author: Ronald Oussoren (ronaldoussoren) *	Date: 2009-03-30 23:01
I propose closing this as won't fix, the issue is caused by a limitation in the Carbon APIs (which assume you're running an eventloop and won't notice changes when you don't).