commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: [POLL][VFS] how to resolve relative filenames
Date Tue, 30 Aug 2005 11:46:25 GMT
Hi Philippe!
>> 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()
Yes, I know - the DIRECTORY case is easy, but lets discuss the case - 
which is to major case for now - where a vfs user do NOT add this 
trailing "/" slash. This is what I meant, VFS needs to check (attach) 
the real type if there is no trailing slash.
You stick a little bit on the trailing "/" problem. You are true if you 
say we can implement it without much hassle for others, be WE still have 
problems with the type-change if this trailing "/" is missing.
Think about the scenarious without trailing "/" and the differences of 
real/virtual files.

> 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
This is not acceptable, the order or resolveFile's in an application 
should not change or preset the behaviour of a filename/object or whatever.

> i think it is necessary to "normalize" "file:///any/name/" and 
> "file:///any/name" to a single name
Yes.

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

> that's why it is important to work on names, not on the real object on 
> the FS
Its easy for a URI to work on names only as it has no other meaning or 
functionality then a pointer to a resource. But we have to access this 
resource and the URI can be wrong.
Thats what my above conclusion tries to address, VFS has to check 
(attach) if the URI is correct (as soon as possible) else an exception 
will be thrown. It is not possible to work on filesystem to with URIs 
without a check to see if they are correct.


---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message