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
a DIRECTORY
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() :
base.attach()
fsm.resolveFile( base, uri )
or
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.
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
