Hi Mario, Just wondering, how would a client of VFS enumerate Just the folders in a directory e.g. in order to Render a tree of files?
He needs to know here what items are folders and What items are files (which gets more difficulte When symbolic links with file-flavor or folder-flavor Are involved, or archives like ZIP and TAR that Can present virtual subfolders). Thoughts? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Mario Ivankovits [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 21. Mai 2008 14:45 > To: Jakarta Commons Developers List > Subject: [vfs] vfs2 or plain wrapper mode > > Hi! > > Probably I find some time during the next weekend to fix a > long standig > bug in VFS regarding dealing with hidden or special files. > > The main problem I see is that VFS tries to act more like a real > filesystem than a simple wrapper. > VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and > then throws > an exception if one tries to open a VIRTUAL file. VFS thinks > such a file > can not exist. > > I'd like to change that behavior from a "fail fast" to a "fail lazy" > one, means, even on VIRTUAL files VFS tries to issue a > getInputStream() > on read. If the underlaying library then throws an exception about > non-existent files this exception will be converted to a VFS > exception. > > The internal file-type is then more like a "guess" and might change on > e.g. getInputStream(). For example, a VIRTUAL file will > become a FILE if > getInputStream() succeeded. > > In the end I'd like to make VFS behave more like a wrapper than a real > filesystem and VFS will pass down each file operation to the > underlaying > library as soon as possible and then normalize the thrown > exceptions to > VFS ones if possible. > > As a side-effect it could be possible to disable this filetype > determination at all (or make it optional) and thus make VFS a lot > faster e.g. with FTP connections where this operation is really really > costly. > > As far as I can see this will lead to a somehow different behavior of > VFS than it is today. It should not influence any existing > applications, > but it might. > So, my questions are: > * [ ] Do you agree that such an evolution might make sense > * and if so, should I > ** [ ] add a VFS-global (static) flag to enable this > wrapper-like-mode or > ** [ ] can I fork VFS to put the current head into > maintainance (or more > correct "dormant") mode and start with e.g. VFS 2.0? > > I'd prefer VFS 2.0. > > Ciao, > Mario > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
