commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject Re: [vfs] parsing uri
Date Wed, 09 Mar 2005 07:36:59 GMT
Hello!
> Sounds like a long night today :-)
Hard work - it might take some time until I can commit the new naming stuff.
The whole procedure of parsing a uri needs to be refactored, currently I 
fight agains the "Layered" stuff e.g. 
tar:tar:file:/dir/first.tar!/second.tar!/entry

And I already "implemented" some incompatibilites between the old and 
the new VFS naming:

Current:
        file = getManager().resolveFile("%2e");
resolves to the current Directory
New:
resolves to a file or directory NAMED "."

Current:
        file = getManager().resolveFile("dir%2fchild");
resolves to a file "child" in directory "dir"
New:
resolves to a file or directory named "dir/child"

Current:
        file = getManager().resolveFile("dir%5cchild");
resolves to a file "child" in directory "dir"
New:
resolves to a file or directory named "dir\child"

I leave it up to the filesystem if such a file or directory could be 
created.

The above examples are those from the unit-test, so the old behaviour 
was wanted. But I think the new one is the right one.
I think it is very unlikely that those constructs can be found in the 
wild life, but if one used VFS that way it IS broken.

Any comments?

---
Mario


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


Mime
View raw message