[Lazarus] Stackable file system abstraction layer

[JoshyFun]

Hello Graeme,

Wednesday, April 23, 2008, 9:07:45 AM, you wrote:

GG> JoshyFun wrote:
>> The demo is a simple file browser with a "Virtual files" folder which
>> is render in "C:\temp\vfile.vfile" (so you need a "C:\temp" folder in
>> order to run the example), the windows disk letters and the ability to
>> mount a zip file as a folder and browse and read it.

GG> Is that similar to TZipFile [http://wiki.freepascal.org/ZipFile]. 
GG> TZipFile is component that allows you to use a zip file like a 
GG> filesystem. You have the usual commands like Create directory, create
GG> file, edit file, view file etc... All directly inside the zip archive,
GG> like you would do with normal files in a file system.

The "demo" is quite similar, but my project is completly different, in
fact the unzip support was accidental :) as I need something to test
code different than native file system.

My class is intented to provide a file system over a file system, over
a file system, and so on, and an application will only need a buch of
changes to be able to use it. In fact the demo can mount "unlimited"
.zip files and copy data from the .zip to any other file system (I had
started the ftp file system) and the main application do not need to
add any kind of special code to handle the "new" file system, unless
it want to perform special functions like set/get attributes, in that
case special support for that layer is needed.

GG> We haven't gotten the actual compression part working yet, but using a
GG> zip file with no compression works perfectly.

The TZipFile code looks pretty and easy to follow, maybe I'll try to
change my "dirty hack" of unzip.pp by the one provided by TZipFile;
but as I say the unzip support is not a must in my case.

GG> I simply thought I would mention this project, as it seems both are
GG> trying something similar. :)

No, my target is a abstraction to access files whichever they are
stored, locally, remotelly, compressed, crypted, or in an unsupported
device (un supported by the OS) but using a single interface to
them; something like the TStream abstraction but for the complete file
system, instead only single media object.

In the other hand maybe this code is better for the fpc project as it
is not intented to be used visually (no visual objects) :-?

Anyway thank you for the feedback.

-- 
Best regards,
 JoshyFun                            mailto:joshyfun at gmail.com