hi Mario,
there is a bug in VFS RC3 :
StandardFileSystemManager fsm = null;
fsm = (StandardFileSystemManager) VFS.getManager();
fsm.setBaseFile( new File( System.getProperty( "user.dir" ) ) );
fsm.setDefaultProvider( new UrlFileProvider() );
F fo = fsm.resolveFile( "file:///path/to/file" );
System.out.println( fsm.resolveFile( fo, "file:///chemin/vers/fichier" ) );
System.out.println( fsm.resolveFile( fo, "/chemin/vers/fichier" ) );
System.out.println( fsm.resolveFile( fo, "chemin/vers/fichier" ) );
output is :
file:///chemin/vers/fichier
file:///chemin/vers/fichier
the last must be :
the same with java.net.URI gives the right result :
URI uri = new URI( "file:///path/to/file" );
System.out.println( uri.resolve( "file:///chemin/vers/fichier" ) );
System.out.println( uri.resolve( "/chemin/vers/fichier" ) );
System.out.println( uri.resolve( "chemin/vers/fichier" ) );

19.08.2005, at 10:07, Philippe Poulard wrote:

hi Mario,

there is a bug in VFS RC3 :

StandardFileSystemManager fsm = null;
fsm = (StandardFileSystemManager) VFS.getManager();
fsm.setBaseFile( new File( System.getProperty( "user.dir" ) ) );
fsm.setDefaultProvider( new UrlFileProvider() );
F fo = fsm.resolveFile( "file:///path/to/file" );
System.out.println( fsm.resolveFile( fo, "file:///chemin/vers/
fichier" ) );
System.out.println( fsm.resolveFile( fo, "/chemin/vers/fichier" ) );
System.out.println( fsm.resolveFile( fo, "chemin/vers/fichier" ) );

output is :

file:///chemin/vers/fichier
file:///chemin/vers/fichier

the last must be :

the same with java.net.URI gives the right result :

URI uri = new URI( "file:///path/to/file" );
System.out.println( uri.resolve( "file:///chemin/vers/fichier" ) );
System.out.println( uri.resolve( "/chemin/vers/fichier" ) );
System.out.println( uri.resolve( "chemin/vers/fichier" ) );

Maybe the URI class is a bit smarter
but why would you use a *file* as a
base anyway?

VFS should probably check whether it's
a dir and if not use the parent.

But IMH the above example looks more
like a wrong use of the API.

my 2 cents

cheers

Torsten Curdt wrote:

19.08.2005, at 10:07, Philippe Poulard wrote:

>hi Mario,
>>
>there is a bug in VFS RC3 :
>>
>StandardFileSystemManager fsm = null;
>fsm = (StandardFileSystemManager) VFS.getManager();
>fsm.setBaseFile( new File( System.getProperty( "user.dir" ) ) );
>fsm.setDefaultProvider( new UrlFileProvider() );
>F fo = fsm.resolveFile( "file:///path/to/file" );
>System.out.println( fsm.resolveFile( fo, "file:///chemin/vers/
>fichier" ) );
>System.out.println( fsm.resolveFile( fo, "/chemin/vers/fichier" ) );
>System.out.println( fsm.resolveFile( fo, "chemin/vers/fichier" ) );
>>
>output is :
>>
>file:///chemin/vers/fichier
>file:///chemin/vers/fichier
>
>>
>the last must be :
>>
>
>>
>the same with java.net.URI gives the right result :
>>
>URI uri = new URI( "file:///path/to/file" );
>System.out.println( uri.resolve( "file:///chemin/vers/fichier" ) );
>System.out.println( uri.resolve( "/chemin/vers/fichier" ) );
>System.out.println( uri.resolve( "chemin/vers/fichier" ) );

Maybe the URI class is a bit smarter
but why would you use a *file* as a
base anyway?

well, it's somewhat obvious :

when you load an HTML document from a web server, you have :

if the document contain :
<img src="picture.jpg"/>
<link rel="stylesheet" href="style.css">
both will be resolved according to the document location :

i think there are many other examples where FILES are referencing
resources they are using

VFS should probably check whether it's
a dir and if not use the parent.

this is not a question of "is it a dir or a file"

if it doesn't end with "/", it must be resolved regarding the parent
if it ends with "/", just append the relative path

But IMH the above example looks more
like a wrong use of the API.

see RFCxxx about URIs

my 2 cents

cheers

Mario Ivankovits wrote:
Hi!

I wont say its a bug from very old code I come to the conclusion
its just not supported that way.

Now this isnt that easy to solve (if we would like to solve it) as maybe
other VFS installations expect it that way.

What we can do is to add a new NameScope - say NameScope.SIBLING.
resolveFile with that scope might behave like URI.

Using FFile(String name, NameScope scope) you could set
it then.

mmmh, consider this :

i hope that a file that ends with "/" is automatically understand by VFS
as a DIRECTRY

so, to resolve "fichier" upon :
file:///path/to/file
that may be an IMAGINARY type
it should be resolved to
file:///path/to/fichier
even if file:///path/to/file is really a directory or a file

to resolve it upon :
file:///path/to/
that must be a DIRECTRY type
it should be resolved to
file:///path/to/fichier

in fact, i'm not sure that an additional scope should be designed ; as
one have all the information for the resolution, i thing the correct
behaviour is the one described above

my previous post show a real example of such a behaviour :

when you load an HTML document from a web server, you have :

if the document contains :
<img src="picture.jpg"/>
<link rel="stylesheet" href="style.css">
both will be resolved according to the document location :

i think there are many other examples where FILES are referencing
resources they are using

the current behaviour of VFS can't process healthily such cases

the current behaviour of VFS can't process healthily such cases

i think that VFS users didn't already have to deal with relative files
resolution regarding something else than a directory ; that's why they
didn't yet complain about this behaviour that is suitable to directories

please have a look again on my HTML example :)

fsm.setBaseFile( new File( System.getProperty( "user.dir" ) ) );

well, it's somewhat obvious :

yepp - but to me the other way around ;)

when you load an HTML document from a web server, you have :

if the document contain :
<img src="picture.jpg"/>
<link rel="stylesheet" href="style.css">
both will be resolved according to the document location :

i think there are many other examples where FILES are referencing
resources they are using

IMH this would only apply if you were
setting a base URI on the fsm.
Matter of fact you are setting a File
object.

But anyway would probably nice to
add a directory check on setBaseFile.
using the parent if it's a file.

cheers

Solving it in "a clean" way might break their application. I think
this is not acceptable for a RC->1.0 release transition.

As long it's not released - it's not released yet ;)

>i think that VFS users didn't already have to deal with relative
>files resolution regarding something else than a directory ;
>that's why they didn't yet complain about this behaviour that is
>suitable to directories
>>
Might be true, but only if their directory-names ends with an "/"
and vfs didnt support this semantic (yet).
So beside fix the filename-resolving stuff we have to add this
"flag" to show we would like to talk about directories even if the
file is "virtual" (non existent)

Adding the "/" semantics right before the release
is not a good idea IM The fix that I proposed
is very simple shoulnd't that do it? It will
much less likely break anything.

In general adding a "special" mode doesn't sound
like a good plan to me.

cheers

Mario Ivankovits wrote:
Hello!

I've read your previous post and all what you outline makes *very* sense.

For sure - its possible to solve it without additional NameScope (even
if hard).
BUT - and I hope other VFS users read this thread too - the behaviour in
this situation isnt well documenten (fault 1), no testcase cover it
(fault 2) and the way it currently works (maybe fault 3) might already
be an assumption for other users and their applications. The only thing
I can say is, that VFS core could couldnt handle it.

Solving it in "a clean" way might break their application. I think this
is not acceptable for a RC->1.0 release transition.

>i think that VFS users didn't already have to deal with relative files
>resolution regarding something else than a directory ; that's why they
>didn't yet complain about this behaviour that is suitable to directories

Might be true, but only if their directory-names ends with an "/" and
vfs didnt support this semantic (yet).
So beside fix the filename-resolving stuff we have to add this "flag" to
show we would like to talk about directories even if the file is
"virtual" (non existent)

K - I suggest to start a poll on the user list and with this result a
vote on the dev list to ask if this "bug" should be solved the clean way
- I do not know every single use of the VFS api (e.g. currently I dont
use this resolve-relative stuff) so I need your input.
This would delay the release for at least another month. - nothing
bad with that.

I vote for fixing this behaviour :)

motivation :

VFS is somewhat a young tool ; people that are developping on RC release
are certainly not as numerous as we think, or didn't yet used the tool
very deeply I guess that the impact is very limited, and in the case
of the few impacted applications, I don't think that adding a terminal
"/" where needed is really difficult

I did myself start to develop with a non-stable version of VFS (january
2005), and it was a pain to upgrade to RC3, because of the unstable API
! however, I'm still ready to accept any drastic changes if they are
justified and contribute to the tool
i'm just considering that things are not as stable as everyone would wish

I'm sure people would prefer a clean-well designed-smart-efficient tool
than a hacked-not fair-unpredictable-dirty one :)

hi,

Mario Ivankovits wrote:
Hi!

Without to spread the feeling a decision has been made ;-) I would like
to discuss another aspect of uri-style resolving names.

First of all, VFS's behaviour on this topic should be consistent, it
should not matter if the directory/file exists or not, the filename is
the only "reality".

this is a sane approach

my proposition is that the resolution algorithm should simply rely on
the type of the base file ; 3 cases :
-the type is explicitely a directory (/path/to/name/)
-the type is implicitely a directory (.createDirectory() or
setType(DIRECTRY))
in both cases, we have a DIRECTRY, we know how to resolve from a base
DIRECTRY
-otherwise the base file is a FILE or IMAGINARY and behaves like a FILE,
we know how to resolve from a base FILE

/path/to/name/
IS a directory
if it doesn't yet exist, .createFile() should call .createDirectory()

/path/to/name
MAY BE a directory
if it doesn't yet exist, .createFile() and .createDirectory() won't do
the same

about names consistency :
/path/to/name/ is a DIRECTRY which name is /path/to/name
/path/to/name is IMAGINARY which name is /path/to/name
createDirectory() switch the file type to DIRECTRY
createDirectory() switch the file type to FILE

now, resolving a file on a base that is implicitely or explicitely a
DIRECTRY can be done

on a web server, when a file have to be resolved, it usually check if
the name is a directory or not ; in the first case, it appends a "/" to
the name ; as you said, VFS must not check it, it must decide only from
the name or from previous operations (such as .createDirectory())

concretely, users that are dealing with names that are considered as
directory must end the name with "/"

warnings :
-additionally, when VFS build a child list, it should mark each item as
FILE or DIRECTRY (i hope it is already the case, as this operation
involves the underlying FS)
-the type of the file (FILE or DIRECTRY) may be fixed when we attempt
to attach it

Consider the following chaing of operations:

01: F fo = VFS.getManager().resolveFile("/any/new/dir/name/")
02: fo.createFile();
03: fo.delete();
04: fo.createDirectory();

Now my questions:
a) Should it be allowed to call createFile on a "directory"? Notice: The
"fo" is nonexistent. Currently the decision if it is a directory or file
will be made when calling one of the create* methods and can be changed
(sure unlikley, but posssible - and if not it is a bug ;-) )

02: fo.createFile() must create a directory, because it's type is
DIRECTRY because its name ends with "/" ($)

b) If we allow to change the type of the file/directory is it logical
that its filename changes too? e.g. after 02: it will be
/any/new/dir/name and after 04 it will be /any/new/dir/name/ again

is it a shortcut on real FS operations, or just a modification on names ?
switching file to dir :
-deleteFile()
-createDirectory()
switching dir to file :
-deleteFile() [and its content]
-setType( FILE ) [otherwise it will create a dir again, see ($)]
-createFile()

c) And thus is it logical that after 02/04 a resolveFile() will behave
differently?

the type rules the behaviour

d) Filename changes are a real problem, not only for the cache (which
could be solved for sure) but also for the application. What if the
application put the fileName object in a map? You might argue after
createFile/createDirectory such application should recreate the
map-entry, but is this really logical?

that's why i propose to delete the trailing "/" from the name ; the
object is the same in the cache and in maps

e) We can ignore b-d if we NT allow to change the type of a file (case
a). In that case the statement on line 02: will fail with an
FileSystemException then.

With way e:

01: F fo = VFS.getManager().resolveFile("/any/EXISTING/dir")

f) should this resolve fail as it exists as directory but the filename
points to a file?

the resolution algorithm doesn't (mustn't) involve the underlying FS, it
just resolves relative names from a base name

K, thats all for now ;-)

Mario

To unsubscribe, e-mail: commons-user-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-user-help (AT) jakarta (DOT) apache.org

about consistency between names and FS :
when /path/to/name/ (which is now a DIRECTRY) appears to be a real FILE
on the underlying FS, i think an exception should be thrown when
attch()ing it, because the user do really think he handles a directory

conclusion, the FileName should also have a FileType ; when attached, it
would be replaced by those of the F ; in fact, when a FileName
is bound to a F, they certainly have the same FileType ; what
is expected in all this stuff is that a standalone FileName (that
doesn't belong to a F) must have a FileType

or something like this :)

Mario Ivankovits wrote:
No answers to this topic?
not during my hollidays :)

Mario Ivankovits wrote:
Hi Philippe!

No answers to this topic?
>>
>not during my hollidays :)

Hope you are full of energy now ;-)

bugs are frightenned of my return ;)

I read your new post and might comment in detail later - overall we are
on the same line, except for one thing:

*Is it really worth it?*

sure !

I am still not convinced in this very basic question. It IS a lot of
work and introduce some new logic a user might have to deal with.
Currently we have a "Very Fine and Simple" (VFS ;-) ) wrapper around
some filesystems and I tried and still try to remove any logic from VFS
which I found not necessary.

this is the reason for which it is necessary to have a *common*
resolution mechanism ; resolving names are scheme independant ; but as i
said in my previous post, a name could contain an information about the
file type : if it is a real DIRECTRY or not ; we are sure if a name
ends with "/", but we should "normalize" names by removing the trailing "/"

URI resolution is really a problem to solve on the foundation of VFS

user side, they just have to append a "/" if they really want to force
VFS to understand a name like a directory (that's what i did in my XML
catalogs)

Everyone is free to add its own VfsUtils.resolveNameURI() class/methods
which behaves the URI way.

too late ! the trailing "/" will be lost after "normalization"
this normalization must be done, because in any case you still have a
problem with "/path/to/name" and "/path/to/name/" ; they musn't be
different, as you noticed it yourself ! the only thing we are sure, is
that the former is a DIRECTRY, the latter is IMAGINARY, until it is
attach()ed or createDirectory() is used

that's why a FileType field is needed in the name ; i noticed that
AbstractF could be easily moved to FileName.type because
its constructor needs a FileName

In difference to VFS which has to deal with filename-types
(directory/file) to work in all cases, such a method might only work if
the file/directory already exists, but I think this is the major case.

well, not really : we are really talking about *name* resolving, which
is (must be) transparent to the underlying FS : resolving names are
scheme independant

example where content is not accessed :
I work with XML catalogs where URIs are resolved from base URIs : when
an entry URI is handled, its content is never used (never attach()ed) ;
the content of the resolved URI on the other side is used
but in some case, it is not used ! for example, it may be use to build a
link ; a web application won't do anything server side with a URI ; the
web browser client side will

Please give me some more arguments other than "your filename looks like
an URI so you should behave like an URI".
Its easy to add a comment on the website which state the filename is NT
a URI.

what would be the consistency of VFS in this case ?
how to resolve *names* with VFS if relative paths were used in HTML
files ?

concessions have already been made regarding URIs by adding semantic to
"!" to allow scheme embedding ; but it was *necessary* ; now what
people would think if they use a tool that is *deliberately* not
compliant to RFCs ?

i already have to deal with such a problem : a vendor was using "URIs"
that were not well-formed regarding RFCxxx ; it looks like this :
"foo://path/to/file" ; but when i parsed the URI, the URI parser tells
that the path part was "/to/file" and the host was "path" ; they simply
forgot a "/" ("foo:///path/to/file"), becaming not compliant with RFCs ;
it doesn't look professional :( ; one solution was to parse twice this
pseudo-URI : 1 to fix the problem, 1 to use the standard URI parser ;
that's what people hate to do : a hack so that they can use their
preferred tools (that are compliant to standards)

you will regret sooner or later to break this ; VFS would be more used
if you proclaim that you are RFC compliant except for the usage of "!"

i'm sure you know i'm right :)