commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject [VFS] troubles with folders
Date Fri, 06 Jan 2006 10:49:42 GMT
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 :
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 :
-some files can contain other files :

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 !!!)


              (. .)
|      Philippe Poulard       |
        Have the RefleX !

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message