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

I have answers :)

On Sat, 5 Oct 2002, Greg Guerin wrote:

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

I disagree. My algorithm may not be *efficient* in that it looks for
directories on platforms where they definitely won't exist, but A)
efficiency isn't relevant, and B) I want something that will adapt to
Mac OS XIV, Windows 2001, unknown future OSes... So it's fine if I find
"/" most of the time, and "C:\", "D:\", etc. on Windows. That's what I
want -- the actual filesystem roots.

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

I will do everything possible to avoid platform-specific imps as it is
easier for the end-users to add new known locations for future OSes than
to incorporate new platform-specific classes into the distro. Or to
distribute an updated known location list. Particularly if the app isn't
being adequately maintained.

> 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

Possibly. However the algorithms described are for a single import
transaction, and could be repeated in full for each import if necessary.
Once the data is imported, there shouldn't be any need to have those
references locations remain mounted or unmounted, as that will be handled
separately when the user requests data on such volumes.

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

In the order shown. Yes, first hit, and yes the user can configure the
ordering of the runtime FOUND_LOCS, which will be prepended to KNOWN_LOCS
when saving back to disk.

> Is FOUND_LOCS itself an ordered sequence? I hope so.

Yes.

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

The program is a single user desktop app. It is fine if FOUND_LOCS
contains inaccessible entries, as these will be culled the next time
FOUND_LOCS is searched for some arachaic path string.

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

Again, this should be OK. The nature of FOUND_LOCS is quite transient, and
can be out-of-synch with the filesystem reality without issue. The idea is
to maximize the number of intelligent places to look for archaic paths
before forcing the user to intervene. On rewriting the locations to disk,
each entry would be checked and if not currently accessible discarded.
KNOWN_LOCS would always be written to disk (or more realistically would
always be read from a separate file than FOUND_LOCS). The user would not
need to cull KNOWN_LOCS (e.g. remove UNIX locations from a Windows
installation) as these would be invisible and culled at each startup. In
other words the user would only ever *see* the list of FOUND_LOCS.

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

There might be, but the user will RTFM :) and know that files are obtained
based on a linear search path, and in the (unlikely) case that they have 2
mounted volumes which both contain, for instance:
"/Video data/2002/Dead Dog Story.mov"
AND these 2 files are not in fact the same logical file, then the first
one found will be used. In practice with our real data sets this issue
doesn't come up.

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

Well, yes. But logically the file is saved at shutdown. In the event of a
crash, the app on next run would see that a temp cache file was never
removed and would prompt the user to restore this cache.

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

I'm looking for maximal robustness given all other constraints :)
Seriously, the robustness of the path mapping algorithm(s) is only
important insofar as it avoids annoying the user with manual intervention
during legacy importing. The data once imported is more robust in itself
and will have many means for resolving data references, including the
worst case where a package loses its manifest. These are designed for and
are unrelated to the import problem.

As for catching signals -- perhaps you mean monitoring the file system for
changes? I'm familiar with signals, but no I'm not catching them for any
reason.

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