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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
