commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Poulard <>
Subject Re: [VFS] uri style resolve names
Date Mon, 29 Aug 2005 09:10:51 GMT

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 
in both cases, we have a DIRECTORY, we know how to resolve from a base 
-otherwise the base file is a FILE or IMAGINARY and behaves like a FILE, 
we know how to resolve from a base FILE

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

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 :
switching dir to file :
-deleteFile() [and its content]
-setType( FILE ) [otherwise it will create a dir again, see ($)]

> 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:
> For additional commands, e-mail:

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


           (. .)
|   Philippe Poulard    |

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

View raw message