Alan.Bateman at Sun.COM
Thu Jul 17 09:52:27 PDT 2008
Alan Snyder wrote:
> It is not obvious to me that abstract pathnames are meaningful only
> for relative path names. No argument has been made to justify this claim.
Perhaps I mis-understand your original mail, but weren't you asking for
a way to represent a path that wasn't tied to a file system or provider?
If so, then any path with a root component (say "C:" or "D:\" or
"\\server\share" or "disk$:" for example) isn't going to readily
translate between providers or into a provider-independent form that you
require. The other complication is of course that you may loose the
internal representation (many file systems use bytes rather than Unicode
strings for example).
> Two possible counterexamples:
> 1. A backup program that creates a catalog of a snapshot of a file
> system could record absolute paths in the catalog.
I don't see any issue here.
> 2. Copying a file from one file system to another could use the same
> absolute path for both the source and the destination. A current
> example of copying between two file systems (providers) would be
> mirroring files onto an FTP host.
The copyTo method can be used to copy between providers. The only
restriction is that some of the meta data may not be copied (because it
don't make sense to the target file system). You can try this out now
with the zip provider to copy files from a zip file system to the
default file system for example. The source and target can be absolute
paths. When you copy from /dir/foo to C:\dir\foo then the paths aren't
the same though (meaning they aren't equal but the String representation
of the names may be equal).
> (I believe that incremental backup and FTP mirroring are basically
> equivalent and can be implemented using a common core.)
> (Perhaps there is a question of how seriously to take the possibility
> of multiple file system providers.
We do expect there will be multiple providers available although the
number will likely be small. Today we don't have a good solution on how
to translate paths between providers (except for Strings which you can
> One direction is to assume that the native file system provider will
> be the interface of choice to all file systems. However, since the API
> allows multiple providers, I'm assuming this feature is intended to be
> supported and useful.)
> I understand that an abstract pathname can be represented as a list of
> strings, and making the conversion easier is a good idea.
It may be "good enough" for most cases but in the longer term we may
need to allow for other representations (bytes in particulars).
> I also understand that there is nothing to stop me from creating my
> own abstract path class (which I have done already). However, since my
> abstract path class is so close to (a subset of) the Path class in
> this project, it seems odd not to be able to use a standard class for
> this purpose.
> Is there an objection other than a desire to limit change to the API?
> Is there a document that explains the design rationale?
Could you expand a bit further on what your abstract path is? (from your
original mail I gathered it's a sequence of names but perhaps there is
More information about the nio-discuss