[ python-Bugs-1004810 ] Carbon.File fails if server vol is mounted after launch

SourceForge.net noreply at sourceforge.net
Fri Aug 6 20:51:16 CEST 2004


Bugs item #1004810, was opened at 2004-08-06 14:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Pharr (pharr)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.File fails if server vol is mounted after launch

Initial Comment:


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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470


More information about the Python-bugs-list mailing list