Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding all mounted volumes

Jason Boyd <email@hidden> wrote:

>2) Have a LocationManager class that on startup does the following
>(pseudocode):
>
>create empty list FOUND_LOCS -- a runtime cache
>load known locations from file into list KNOWN_LOCS
>obtain list ROOTS (File.listRoots())
>foreach ROOT in ROOTS
> foreach LOC in KNOWN_LOCS
> if ROOT/LOC exists and is a directory, cache in FOUND_LOCS
> cache ROOT in list FOUND_LOCS

The usefulness of File.listRoots() for what you want to do is
platform-dependent. It's useful on Windows, but not very useful on Mac OS
X or Linux, where it always and only returns "/".

So instead of having the general case enumerate the roots, I'd let a
platform-specific imp enumerate roots only as appropriate for the platform.
The file listing KNOWN_LOCS is on every platform, but I see no reason not
to let a platform's imp handle that, too. The method imp might be in the
base class, but the invocation should be in the concrete imp.

I think I'd separate FOUND_LOCS (or possibly KNOWN_LOCS) into a list of
non-dynamic locations, and another list of dynamic locations. "Dynamic
location" basically means a point (mount-point) whose contents may change
over time, so is worth watching with a dynamic algorithm over time. Not
every location is going to be worth watching dynamically, so it may pay to
make the distinction. Dynamic locations may also affect the contents of
FOUND_LOCS over time ("invalidating cache entries", so to speak).


>3) When a legacy path is encountered, use the following approach:
>
>parse into 3 items: VOLUME, PATH, and FILENAME (trivial; known format)
>foreach LOC in FOUND_LOCS
> if LOC/PATH/FILENAME exists OR
> LOC/VOLUME/PATH/FILENAME exists OR
> LOC/*/PATH/FILENAME exists (iteration implied; not actual wildcard)
> then use the found file

What order do you search in? Do you stop on first hit, or find all hits
and let user choose (presented in priority order), or is that configurable?

Is FOUND_LOCS itself an ordered sequence? I hope so.

Is FOUND_LOCS ever purged of stale or inaccessible entries? How long does
the program itself run?


> chop /PATH/FILENAME from found path; add to FOUND_LOCS if not present
> done
> else
> prompt user to
> insert disk containing PATH/FILENAME (suggest VOLUME as name)
> or specify the location of FILENAME
> if user inserts a disk, repeat above steps from #2 (optimize later)
> else if user specifies file location (and file exists)
> if PATH precedes specified file
> add directory containing PATH to FOUND_LOCS
> else ask user for further steps -- add location, move file, etc.

For a user to insert a disk, they may have to eject (dismount) one. What's
that going to do to your FOUND_LOCS list of known locations, or are you
sucking in an entire disk when it's inserted?

Do the disks themselves contain material that might be ambiguously named
under the union of all their namespaces? That is, can there be a
PATH/FILENAME that could exist on more than one disk, but actually being
two completely different files? For example, might there be a
"util/plain.txt" on two or more disks, with different contents?


>4) On system shutdown, save FOUND_LOCS and KNOWN_LOCS (ordering is
>significant) to known locations file.

I'd save it more frequently than that, like shortly after it changes
(write-back caching). You'll be in a better position to survive unexpected
termination that way. Even if your program never crashes, someone else
might.

What kind of overall robustness are you looking for? Is it
platform-dependent? Are you catching signals?

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.