commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject [VFS] uri style resolve names (was: [VFS] bug ?)
Date Tue, 23 Aug 2005 08:25:23 GMT
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


Mime
View raw message