[vfs] vfs2 or plain wrapper mode

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[vfs] vfs2 or plain wrapper mode

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [vfs] vfs2 or plain wrapper mode

Oberhuber, Martin
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:[hidden email]]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] vfs2 or plain wrapper mode

Filip Defoort
In reply to this post by Mario Ivankovits
Hi Mario,

On 5/21/08, Mario Ivankovits <[hidden email]> wrote:
> 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?
>

This sounds great - I think what you're describing makes a lot of
sense (and would actually solve some long standing bugs + performance
issues).

Since the behavior may drastically change, I'd suggest to fork and go
for VFS 2.0 rather than a static flag.

Cheers,
- Filip

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] vfs2 or plain wrapper mode

Mario Ivankovits
In reply to this post by Oberhuber, Martin
Hi Martin!
> 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?
>  
As today. Disabling the file-type determination should be optional only
and isn't something I'd change during the first development iteration.

The difference to today is that VFS will allow you to try to enumerate
even on files where it thinks it is a file or virtual. And only if the
underlaying library throws an exception the operation will fail.
What I'd like to open up is just to ignore what VFS thinks about a file
and try to read it anyway. This should make it possible to also deal
with special files and also hidden files which will look like a virtual
file for VFS - and make VFS unable to handle them today.

On filesystem level than (through our FileSystemOptions) it might be
interesting to allow to disable the file-type determination at all which
will make ftp access a lot faster, even if some file informations are
missing then. But polling a ftp directory for new files will be as fast
as when using plain ftp then.

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] vfs2 or plain wrapper mode

Jeffrey Brekke
In reply to this post by Mario Ivankovits
We also have the situation where the directories are also hidden.  So we
need to be able to traverse hidden directories as well.  Sounds like your
solution would work for directories as well, if VFS didn't attempt to
enumerate all the files in all the directories along the path?

On Wed, May 21, 2008 at 7:45 AM, Mario Ivankovits <[hidden email]> wrote:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Jeffrey D. Brekke
Wisconsin, USA

brekke at apache dot org
ekkerbj at gmail dot com
jbrekke at wi dot rr dot com
Reply | Threaded
Open this post in threaded view
|

Re: [vfs] vfs2 or plain wrapper mode

Mario Ivankovits
Hi!
> Sounds like your
> solution would work for directories as well, if VFS didn't attempt to
> enumerate all the files in all the directories along the path?
>  
Yes, that is the plan :-)
What I wrote about files count for directories too, for me this
attribute is just a different value ;-)

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [vfs] vfs2 or plain wrapper mode

Jörg Schaible-2
In reply to this post by Mario Ivankovits
Mario Ivankovits wrote:
[snip]

> So, my questions are:
> * [X] 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
> ** [X] 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.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [vfs] vfs2 or plain wrapper mode

Jeffrey Brekke
In reply to this post by Mario Ivankovits
> * [X ] 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
> ** [X ] can I fork VFS to put the current head into maintainance (or more
> correct "dormant") mode and start with e.g. VFS 2.0?
>

--
Jeffrey D. Brekke
Wisconsin, USA

brekke at apache dot org
ekkerbj at gmail dot com
jbrekke at wi dot rr dot com