You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Philippe Poulard <Ph...@sophia.inria.fr> on 2005/08/19 10:07:46 UTC
[VFS] bug ?
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() );
FileObject 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
file:///path/to/file/chemin/vers/fichier
the last must be :
file:///path/to/chemin/vers/fichier
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" ) );
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Torsten Curdt <tc...@apache.org>.
>>> 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 :
> http://www.acme.com/path/to/document.html
> if the document contain :
> <img src="picture.jpg"/>
> <link rel="stylesheet" href="style.css">
> both will be resolved according to the document location :
> http://www.acme.com/path/to/picture.jpg
> http://www.acme.com/path/to/style.css
>
> i think there are many other examples where FILES are referencing
> resources they are using
IMHO 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
--
Torsten
Re: [VFS] bug ?
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
Torsten Curdt wrote:
>
> On 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() );
>> FileObject 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
>> file:///path/to/file/chemin/vers/fichier
>>
>> the last must be :
>>
>> file:///path/to/chemin/vers/fichier
>>
>> 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 :
http://www.acme.com/path/to/document.html
if the document contain :
<img src="picture.jpg"/>
<link rel="stylesheet" href="style.css">
both will be resolved according to the document location :
http://www.acme.com/path/to/picture.jpg
http://www.acme.com/path/to/style.css
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 IMHO the above example looks more
> like a wrong use of the API.
see RFCxxx about URIs
>
> my 2 cents
>
> cheers
> --
> Torsten
thanks for your reply
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Torsten Curdt <tc...@apache.org>.
On 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() );
> FileObject 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
> file:///path/to/file/chemin/vers/fichier
>
> the last must be :
>
> file:///path/to/chemin/vers/fichier
>
> 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 IMHO the above example looks more
like a wrong use of the API.
my 2 cents
cheers
--
Torsten
Re: [VFS] bug ?
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
>
> 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 :)
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> 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 ;)
Hmmm. Maybe I "overcomplicate" things ...
>>> 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 IMO.
... but its not release yet ;-)
> The fix that I proposed
> is very simple ...shoulnd't that do it?
Yes and no. Yes it might work, but - no - only if the file already
exists. And why should the filename parsing stuff take the existence of
a file/directory into account? In fact at that point in VFS I do only
have a FileName and no FileObject.
Philippe wrote:
> I vote for fixing this behaviour :)
I need some time to think about it.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Torsten Curdt <tc...@apache.org>.
> 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 IMO. 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
--
Torsten
Re: [VFS] bug ?
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
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)
>
>
> OK - 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. Ok - 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 :)
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Mario Ivankovits <ma...@ops.co.at>.
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)
OK - 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. Ok - nothing
bad with that.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
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 FileObject.resolveFile(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 DIRECTORY
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 DIRECTORY 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 :
http://www.acme.com/path/to/document.html
if the document contains :
<img src="picture.jpg"/>
<link rel="stylesheet" href="style.css">
both will be resolved according to the document location :
http://www.acme.com/path/to/picture.jpg
http://www.acme.com/path/to/style.css
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
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] bug ?
Posted by Mario Ivankovits <ma...@ops.co.at>.
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 FileObject.resolveFile(String name, NameScope scope) you could set
it then.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] uri style resolve names
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
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 DIRECTORY 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 DIRECTORY, 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
AbstractFileObject.type 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 NOT
> 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 :)
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] uri style resolve names
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Philippe!
>> No answers to this topic?
> not during my hollidays :)
Hope you are full of energy now ;-)
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?*
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.
Everyone is free to add its own VfsUtils.resolveNameURI() class/methods
which behaves the URI way.
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.
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 NOT
a URI.
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] uri style resolve names
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
Mario Ivankovits wrote:
> No answers to this topic?
not during my hollidays :)
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] uri style resolve names
Posted by Mario Ivankovits <ma...@ops.co.at>.
No answers to this topic?
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [VFS] uri style resolve names
Posted by Philippe Poulard <Ph...@sophia.inria.fr>.
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(DIRECTORY))
in both cases, we have a DIRECTORY, we know how to resolve from a base
DIRECTORY
-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 DIRECTORY which name is /path/to/name
/path/to/name is IMAGINARY which name is /path/to/name
.createDirectory() switch the file type to DIRECTORY
.createDirectory() switch the file type to FILE
now, resolving a file on a base that is implicitely or explicitely a
DIRECTORY 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 DIRECTORY (i hope it is already the case, as this operation
involves the underlying FS)
-the type of the file (FILE or DIRECTORY) may be fixed when we attempt
to attach it
>
> Consider the following chaing of operations:
>
> 01: FileObject 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
DIRECTORY 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 NOT 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: FileObject 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
>
>
> OK, thats all for now ;-)
>
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
about consistency between names and FS :
when /path/to/name/ (which is now a DIRECTORY) 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 FileObject ; in fact, when a FileName
is bound to a FileObject, they certainly have the same FileType ; what
is expected in all this stuff is that a standalone FileName (that
doesn't belong to a FileObject) must have a FileType
or something like this :)
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
[VFS] uri style resolve names (was: [VFS] bug ?)
Posted by Mario Ivankovits <ma...@ops.co.at>.
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".
Consider the following chaing of operations:
01: FileObject 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 ;-) )
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
c) And thus is it logical that after 02/04 a resolveFile() will behave
differently?
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?
e) We can ignore b-d if we NOT 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: FileObject fo = VFS.getManager().resolveFile("/any/EXISTING/dir")
f) should this resolve fail as it exists as directory but the filename
points to a file?
OK, thats all for now ;-)
---
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org