commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject Re: [POLL][VFS] how to resolve relative filenames
Date Tue, 30 Aug 2005 11:12:18 GMT
Mario Ivankovits wrote:
> 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 "/".

I disagree : "/path/to/dir/" denotes definitively a DIRECTORY ; don't 
need to attach()

> 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 
> directory/imaginary?
> 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 proposed that in any case, "file:///any/name/" and "file:///any/name" 
would should both be "normalized" to "file:///any/name" ; if a FileName 
object needs to be created, the former must have a flag that states that 
it is a DIRECTORY, the latter an IMAGINARY file
now, what could happenned if a file is in the cache ?
1) "file:///any/name/" create the file name "file:///any/name" which is 
a DIRECTORY, put it in the cache
2) "file:///any/name" retrieve the entry in the cache, which is known as 
the other scenario :
1) "file:///any/name" create the file name "file:///any/name" which is 
an IMAGINARY, put it in the cache
2) "file:///any/name/" retrieve the entry "file:///any/name" in the 
cache and change its type to DIRECTORY

as you see, before forcing attach(), there are many cases where a file 
is *known* to be a directory :
-if the cache tells that "file:///any/name" is a directory, believe it
-if the name ends with "/", it is a directory
-if the name doesn't end with "/" but i force the type to be a directory
i think it is necessary to "normalize" "file:///any/name/" and 
"file:///any/name" to a single name ; i think it is important that a 
FileName must have a flag that denotes if it is a DIRECTORY or not

attach() should be used in a last resort if this flag is missing ; this 
allows to work on *names* without involving the FS, which may be a 
bottleneck for remote FS

moreover, users should have the choice to invoke themselves attach() :

fsm.resolveFile( base, uri )


fsm.resolveFile( base, uri )

there is a last point : what about files that doesn't exist on the 
underlying FS ??? attach() won't help in this case ; users must be able 
to state on the type of such file, either by naming it with a trailing 
"/", or by forcing the name to be a DIRECTORY

that's why it is important to work on names, not on the real object on 
the FS

> I admit, a very uncommon situation, but we have to deal with it.


           (. .)
|   Philippe Poulard    |

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

View raw message