On Wed, 2 Jul 2008 14:59:40 "Sorin Negoita"
<email@hidden> wrote:
Are you sure you test it using just one process ? I use to run
this code in a loop with a sleep to have enough time to unmount/
mount the stick. If I restart my process after unmount/mount,
everything works perfect.
I was testing it from within a single run of a GUI app where
the code mentioned was called as result of menu command. Indeed,
if I do this from a command line app that doesn't run events
in a for (;;) loop with a "sleep" I observe what you are talking
about (though the error returned back from OpenIterator call is
-36 = "I/O error (bummers)". While FSPathMakeRef call succeeds).
Interestingly, when testing in a GUI app (that runs event loop)
the FSRefs returned to me by FSPathMakeRef are different --
checked with CompareFSRefs -- even if I *do not* unmount/remount
the disk, while when testing in the CLI app (that doesn't run
events) the FSRefs returned are equal (even after unmount/remount).
I think this might be explained this way: File Manager does some
updating of its internal structures (apparently volume list) only
if you run event loop. Whether this is a bug or a feature, hmm...
Some FM calls are affected by this caching (e.g. OpenIterator) while
some don't (e.g. FSPathMakeRef). As a workaround, can you run
event loop (Carbon, Cocoa or CF)?
My stick is FAT-16 if that matters.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
