<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 3, 2016 at 9:39 PM, José Mejuto <span dir="ltr"><<a href="mailto:joshyfun@gmail.com" target="_blank">joshyfun@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>El 04/09/2016 a las 2:04, silvioprog escribió:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If I understood right, did you create something like GIO or GVFS? Or<br>
neither of them hehe<br>
</blockquote>
<br></span>
Hello,<br>
<br>
Yes and no :) It's something like GVFS but at your program level only. I originally develop it to be used in a forensic tool (which was not finally developed) to allow the same data scan engine to work in compressed files as they were real files so the file access logic is completly isolated from the information gather engine as this one works over a TVirtualFileSystem, how you implement your TVirtualFileSystem is up to your decision.<br>
<br>
You basically need to implement this functions:<br>
<br>
function intfOpenFile(const AFileName: UTF8String; const AMode: cardinal): TvlHandle; virtual; abstract;<br></blockquote><div>[...]</div><div><br></div><div>Nice API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As far as you can implement those functions yes, in fact I started (almost nothing) to write an http access using a remote zip file for read only and using the http byte ranges to access it.<br></blockquote><div><br></div><div>I spent a much time working in an efficient byte serving layer, because the company needed to provide files allowing resume of up/download contents. I did it with raw TFileStream, but I need to spend some time testing TBufferedFileStream, I think this class can be very useful for creating fast layer allowing download acceleration of big files (that has sequencial small repetitive reads), and I've already implemented a structure allowing the following simultaneous byte range groups:</div><div><div><br></div><div>     HTTP/1.1 206 Partial Content</div><div>     Date: Wed, 15 Nov 1995 06:25:24 GMT</div><div>     Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT</div><div>     Content-Length: 1741</div><div>     Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES</div><div><br></div><div>     --THIS_STRING_SEPARATES</div><div>     Content-Type: application/pdf</div><div>     Content-Range: bytes 500-999/8000</div><div><br></div><div>     ...the first byes range...</div><div>     --THIS_STRING_SEPARATES</div><div>     Content-Type: application/pdf</div><div>     Content-Range: bytes 7000-7999/8000</div><div><br></div><div>     ...the second bytes range</div><div>     --THIS_STRING_SEPARATES--</div></div><div><br></div><div>ASAP I'm going to redo my benchmarking tests replacing the TFileStream to TBufferedFileStream and checking if I really can get any performance gain.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe I should retake this work :) if there are some interest in the community.<br></blockquote><div><br></div><div>Searching files under compressed files seems really seems a very useful feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Attached is a sample (some folder names erased) of the explorer I use to test the different file systems in "real" situations.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">I took a look at it, thanks! :-)</div><div class="gmail_extra"><br></div>--<br><div><div dir="ltr"><div>Silvio Clécio</div></div></div>
</div></div>