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 18:31:47 GMT
> it must not : before VFS, I already disciplined myself and always name 
> my directories with an ending "/" ; i'm always sure what i'm handling :)
You strip the rest of my mail so I would like to append it here again:

The ONLY way I can see is to force the user to append the trailing "/" 
ALWAYS if he would like to work on a directory, else it is a file.
It is no longer possible to work on "imaginary filanames".
The type can not be changed with a createDirectory/createFile.
The type of the filename says all.
AND VFS has to attach the file on resolveFile to check if the requested 
type corresponds to the reality if the file/directory is already existent.
e.g. The request for file://any/dir will fail if it is existent and a 
directory, on the other hand a createDirectory() will fail as the 
filename points to a "file" not a directory.

There is still the problem with imaginary files and the order of 
resolveFile in threading. But then we will have a fail fast (vfs will 
throw an exception too) and this is somehow arguable and as I said a not 
very common situation.

> people that use won't switch to VFS if they don't 
> recognize the behaviour they know
Then the question is: Why should one use VFS?
If no physical access is needed and URI do its job then go on with it, 
once you would like to access a resource you can pass the URI as string 
to VFS.

> if you still decide to ignore these important stuffs, you dramatically 
> restrict the application scope of VFS ; it would be a pain to hack VFS 
> in the aim of having a correct behaviour :(
Please dont say I igonre important stuff, I hardly try to understand 
your needs and I try to tell you its implimications.
My main VFS usage is in an web-application as singleton and so there is 
only one fileName and fileObject instance per resource in the whole JVM. 
To have a flag and switch it back and forth  WILL break threaded (and 
thus web-) applications.
What ever you would like to have, you have to take this into account.

> as i said previously, a flag should indicates on *FileName* if it is a 
> directory or not ;
> it could be a free field that a user could set at convenience
no! not possible, every filename is a singleton in an jvm instance.
> , but that is set automatically to true if the name ends with "/" ;
> a custom resolveFile() method can't be considered if this flag is missing
I know, and I expected it only to work when the resource is "reachable", 
but ok, I understand that this is bad too.

> remember that the more you are compliant with RFCs, the more VFS will 
> be use :)
hmmmm .... now that we are the only two discussing this topic I would 
suspect that other user really need this feature, BUT HEY - I take you 
seriously, I promise, maybe we just cant see the value of the URI solution.

I will try to widen this discussion and setup a text which I will send 
you per PM. If you agree with the content I will post a poll on the 
developer list. Maybe we can get additional input from there.


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

View raw message