hi Mario, and happy new year !

I'm testing the enhancements about URI/File style
I'm using VFS-RC7 :

         StandardFileSystemManager fsm = null;
         VFS.setUriStyle( true );
         fsm = (StandardFileSystemManager) VFS.getManager();
         String dir = System.getProperty( "user.dir" ) + "/";
         fsm.setBaseFile( new File( dir ) );

but it doesn't work because File seams to strip the last "/" that I 
added to mark that it was a folder
thus, after the resolution, it appears that the base file is NOT a 
directory, which makes following relative resolutions fails

---------------------

I notice that there were some enhancements in the code, for example that 
a parent file is always a folder

---------------------

there's something strange to me :
http://host:port/path/to/folder/
might have a content, and is returned as a FileType.FILE

what is the definition of a file and of a folder ?
-a file can't contain other files and may have a content
-a folder can't have a content but may contain files

but it appears that it is not always true :
-some folders can have contents :
http://host:port/path/to/folder/
-some files can contain other files :
zip:file:///path/to/file.zip!/path/to/inner/file

a path name that ends with "/" is definitively a folder (I notice that 
when VFS parses names, the last "/" is stripped and the file is marked 
as FileType.FOLDER, so everything is ok)

isn't that conflicting to have a folder (its name ends with "/") that 
has a content, so that is a file ???

notice that I created the XML:DB provider that works almost like http in 
the way that a folder may have a content ; i did the trick like this :

     public InputStream getInputStream() throws FileSystemException {
         try {
             return super.getInputStream();
         } catch ( FileSystemException fse ) {
             if ( fse.getCode().equals( 
"vfs.provider/read-not-file.error" ) ) {
                 // XML:DB directories might have content
                 try {
                     return doGetInputStream();
                 } catch (final Exception exc) {
                     throw new 
FileSystemException("vfs.provider/read.error", this.getName(), exc);
                 }
             } else { // propagate error
                 throw fse;
             }
         }
     }
in this case, I really have a FileType.FOLDER that has a content, but 
it's a hack

additionally, it would be kind if the error codes could be defined as 
constants : the trap would be more reliable if there were a binding with 
the error string, than a character comparison (if you change a single 
char, all that will fail !!!)

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

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