commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Lewis <>
Subject Re: [VFS] VFS.getManager().getFilesCache() - exists() vs findFiles()
Date Thu, 19 May 2005 12:58:25 GMT

Taking a cursory look through the code, I have a couple of thoughts.

First, what about adding a stat() method on FileObject, something akin
to the SftpFileOjbect.statSelf(). I know that is an API change, and
while this doesn't exist in many of the providers, and may not be
relevant for some, it is a pretty "normal" file system operation. Adding
a default empty implementation to AbstractFileObject() would cover most
implementations. From a logical standpoint, vfs deals with remote
systems, so the need to periodically refesh that attribute and status of
a file should not be an uncommon thing. I can see many reasons for
wanting to refresh the state though. Then if any FileObject is resolved
to the cache, and appears to be deleted, stat() could be called before
returning it to insure the state is correct when the caller gets it.

As a simpler, more immediate "hack" fix - it looks like it might be
possible to fix the specific case of FileObject.findFiles(). Since
AbstractFileObject.findFiles() relies on getChildren(), which gets the
names and then resolves the file, it should be posible to assume that
any filename returned in the traverse() is not deleted, and for a status
change immeidately after the resolveFile() if it is marked deleted. This
would be an ideal time to call a FileObject.stat() routine if we had one.

While it might not solve every case, for example, if you resolve a
cached deleted file from a URL using FileSystemManager.resolveFile() -
how would that show up? (haven't tested it)

Anyhow, just some thoughts - I have spent realtively little time in the
vfs code, although I have used it quite a bit - AWESOME bit of work in
my opnion, with HUGE potential for the future. I wish I had more time to
help with it....

Mario Ivankovits wrote:

> manco wrote:
>> ok,  I was thinking the cache was some type of Singleton per jvm,
> It is a singleton per VFS Manager.
>> but it sounds like from
>> your answer that it is FileObject specific.
> No, then I was not clear enough.
> VFS do have 2 "caches".
> 1) One which holds the fileObjects
> 2) and a second is the fileObject which caches its own state.
> now a resolveFile/findFile utilize the first to return always the same
> instance of a fileObject to any thread.
> This allows one to synchronize against this instance.
> FileObject.close() reset the states of case#2.
> Cioa,
> Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message