commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [POLL][VFS] how to resolve relative filenames
Date Tue, 30 Aug 2005 06:26:23 GMT
Philippe Poulard wrote:
>> [X] Use URI style
>> [ ] Keep current behaviour
> people that vote for the second choice should consider this :
> are your applications really impacted ?
> i don't think so;
In fact it is impacted.

Lets summarize again:
 From "URI point of view" every filename in VFS points to a directory 
and thus resolveName resolve relative to this name - NOT to the parent.
1) file:///path/to/dir , any/file = file:///path/to/dir/any/file
2) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file

With "URI style" and NO synchronization (attach) to the filesystem:
3) file:///path/to/dir , any/file = file:///path/to/any/file
4) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file

With "URI style" and WITH synchronization (attach) to the filesystem:
5) file:///path/to/dir , any/file = file:///path/to/dir/any/file
6) file:///path/to/dir/ , any/file = file:///path/to/dir/any/file

Not only that the change to "URI style" resolving might break existing 
applications (difference between 1+3) it requires to attach to the 
filesytem to avoid this problem (5).

> notice that URI resolution is scheme independant and applies only on 
> FileName, not on FileObject 
But this is just a matter of definition, we are also free to say the 
current resolution is scheme independant. The current way is surely not 
RFC compliant, the question is if the URI resolve thing is the best idea 
for filesystems.

> (VFS doesn't need to attach() the file to the underlying file system 
> to lookup by itself if it is a real file or directory, except if a 
> user explicitely attach() the file)
As you might see, VFS needs to attach the file to resolve correctly if 
the user do NOT always state a directory with the leading "/".

Now that we see we have to attach the file the question is if we simply 
change resolveFile to check if the base-fileObject is a file or 
In the first case we ask the parent fileObject to resolve in the latter 
we resolve like today.
BUT - this is something a user can do today with its own 
VfsUtils.resolveFile() method.

Then there is still the problem to mark a filename as directory in advance.

If you use VFS as singleton (VFS.getManager()) and resolve the same file 
you will get the SAME FileObject/FileName instance. e.g. it allows 
threads to synchronize against a fileobject.
Now what if the first thread uses "file:///any/name/" and the second 
uses "file:///any/name" - the first thread should see a filename in 
state DIRECTORY and the second in state IMAGINARY until the file is 
attached or created.
I admit, a very uncommon situation, but we have to deal with it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message