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

Greg,

Generally I think you're a total guru. You're helping verify my own
suspicions about the mounted "volume" issue, but there are some things I'm
still seeing differently:

> It's not exactly a common everyday problem. Most media stays with one
> machine (or machine family), or if it moves around it's expected that each
> machine will deal with it on its own terms.

The problem that *does* seem like it should be common, which I think is
being misunterstood here, is to simply enumerate all available disks. I
realize there are numerous standard and not-so-standard ways volumes might
be mounted, and that these can't be 100% detected without human
intervention, but it doesn't seem that crazy to want to be able to know
from code: is there a CD mounted? How many disks are there, including
floppies, Zip drives, images, etc? I may have made it sound more
complicated by implying I would be searching for a specific named volume,
which isn't the thing I'm saying is commonplace. But read on...

> A Pathname and appropriate PathnameFormat can parse the form you've given
> with ease. You can then do what you want with the constituent parts
> (between the separators), using the PathnameFormat appropriate to the host
> platform (provided in my open source Easy Posix Toolkit).

Useful tip but parsing the pathname isn't the trick. I have as a given
that ":" is the legacy file separator; the first token is the Mac Classic
volume name; the rest is a path from that volume's root. Of course I may
have to escape other characters like "/" or "*", so using the above
classes may be wise.

> Mapping "Foobar CD" onto some relevant base location is going to be
> platform-specific, and probably configuration-specific. For example, it
> might be an actual drive on one Windows machine, but a share on another.
> ...
> several more valid points...


OK, so what is wrong with this approach:

1) Have an initial set of loaded properties specifying some known
locations (*not* absolute paths) for the intended OSes. E.g. "mnt",
"Volumes", "dev", etc. Allow users to add, remove, and reorder locations
from within the application. (This user interaction would not typically be
required, but would need to be allowed.)

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


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
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.

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


It seems to me this accomplishes:

A) Best possible attempt to automagically locate files if they are on a
mounted volume at all, minimizing user intervention
B) Adapts to actual accessible volumes on each run, including one-time
user added paths. Adapts (somewhat) to user mounting/unmounting disks.
C) Is OS agnostic (doesn't do anything differently based on the OS) but
is pre-configured with some OS-specific heuristics
D) Allows user to prioritize locations, so multiple file matches are
unambiguous

By way of example, if looking for legacy path
"Foobar:some:path:file"
this approach should automatically find any of the following:

C:\some\path\file
G:\some\path\file
C:\Documents and Settings\All Users\appname\assets\some\path\file
F:\Documents and Settings\jason\some\path\file
/Users/jboyd/appname/assets/some/path/file
/mnt/cdrom/some/path/file
/Volumes/Foobar/some/path/file
/Volumes/Foobar 2/some/path/file
/Foobar/some/path/file
/dev/hda2/some/path/file
/some/path/file
/usr/local/appname/assets/some/path/file
C:\Program Files\appname\assets\some\path\file
<user-set location>/some/path/file

Et cetera. So again, what's wrong with this approach?
_______________________________________________
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.
References: 
 >Re: Finding all mounted volumes (From: Greg Guerin <email@hidden>)



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.