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:

>Actually this seems completely incorrect. The path I gave:
>Foobar CD:Some Directory:subdir:file.ext
>
>would not be a valid path on any of the above OSes, with or without the
>"Foobar CD" portion (and of course translating : into a valid file
>separator). Nontheless this is the legacy data I need to handle, so I need
>to make all possible attempts to resolve such a path.

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

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.

You may also have platform-specific name constraints to deal with. For
example, filenames on Mac OS can contain "/", "*", and other characters
that are forbidden on some platforms. I'm not sure what the host OS does
if, say, a CD-ROM with such a filename is mounted on a platform that
forbids such things.


>In the case where
>the user has the original CD, this would appear to be:
>
>OS X -- "/Volumes/Foobar CD/Some Directory/subdir/file.ext"

Good guess, but not necessarily. The "Foobar CD" name will be uniqued in
"/Volumes" so that every pathname to every mounted volume is guaranteed
unique for the time the volume is mounted. For example, if a second
"Foobar CD" were mounted (or a share called "Foobar CD"), then the name
would be "/Volumes/Foobar CD 2". The names may change as volumes are
mounted and unmounted, too, which is another source of endless fun.

You can observe this by making a disk-image, duplicating it, and then
mounting the duplicate, too. The Finder shows 2 items of the same name.
But an 'ls -l /Volumes' shows 2 unique names.


>The point is, I can't just go with
><File.listRoots()>[/Foobar CD]/Some Directory/subdir/file.ext
>because this will definitely not work most of the time on any of the
>platforms.

Exactly right. You could have different code (concrete subclass) of some
abstract VolumeMapper class, and select an implementation based on platform
and other heuristics. But any fully automatic VolumeMapper will either be
prone to mistakes, or be so complex to write, that you will have to
supplement it with human intervention.


>[...] However, so far I've
>avoided tailoring anything to any platform and I'd still like to find
>agnostic approaches in general. In this case it doesn't seem like it ought
>to be so difficult to enumerate *standard mount points* if that clarifies
>the disks/volumes/whatever term.

Even if you enumerate standard mount points, you have a name-resolution
problem. That is, the "Foobar CD" in the legacy data will not necessarily
be visible or ascertainable on the host platform. Even using heuristics
that try to match candidate mount points to known structure of the legacy
data.

That is, even if your code knows that "Foobar CD" contains 3 directories
named "Larry", "Curly", and "Moe", and 4 files with certain names and
sizes, there may be more than one candidate mount-point that meets the
criteria, or there may be none. What then?

Or say your program finds only one candidate mount-point, starts working,
and eventually finds a legacy pathname that doesn't exist on the chosen
mount-point. What then?


>It surprises me that no one has had to do
>just this, or at least no one is giving a simple solution. Even Sun's
>documentation and tutorials seem to have nothing relevant.

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.

You're converting a specific legacy pathname structure into a new form
while preserving the implicit structure in the original naming scheme. It
may seem simple or commonplace to you, but I don't really think it happens
too much, and even less frequently in a completely platform-neutral way.
Pathnames just aren't portable.

By the way, the closest thing I can think of to a universal pathname form
is a URL. But File.toURL() may not cut it, because it will encode the host
platform's idea of a URL, which is not the same as a portable URL. That
is, move the media to another platform and the URL may be different. This
shouldn't be too surprising, since URL's were never intended for doing this.

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