Hi Mario, Calling directory.close() before directory.getChildren() helps indeed. But it isn't nice at all especially because this is the default behavior. It will definitely require addressing.
I think a distinction should be made between short runs (e.g. Ant task) and long runs (like a file manager) for VFS. By default a long running task should be considered as happening (so no caching). If a client knows that it needs a short running task then it should configure VFS accordingly. However the default setting should provide a real time view of the file systems. I don't know, but shouldn't this behavior considered as an (architectural) bug? Regards, Robert On 11/23/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi Robert! > > For instance FileObject.getChildren() by default returns the same > children > > across multiple calls regardless of the changes that happened on the > disk > > between two identical calls. > > > This is already a todo on "VfsNext". > > For now, you can call "foDirectory.close()" to refresh its children data. > > > standardManager.setFilesCache(new NullFilesCache()); > > > Please dont use any other FilesCache than the default, they will lead to > memory leaks and/or some other problems as you found out. > And this sort of cache is other than the local cache the *FileObject > uses, so the FileObject wont refresh its cache even if you use this > NullFilesCache. > > > Hope this helps for now. > --- > Mario > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
