Checksum via FTP???

Roger Eller roger.e.eller at
Sun Sep 11 14:49:28 EDT 2011

On Sun, Sep 11, 2011 at 2:22 PM, Richard Gaskin wrote:

> Roger Eller wrote:
> > for protecting the initial md5digest, I might store it in
> > a database rather than a file.  That could possibly make retrieval
> > of that code more efficient, and also add a protective layer.
> If someone has sufficient access to modify files on your server, that may
> include your database as well.
> Databases are handy for working with very large data stores, esp. where you
> need relationality but for simple things like a checksum value for a file,
> Mark Weider's suggestion is probably the simplest and most efficient, to
> just store a checksum file with the actual file,
> With a database your client talks to Apache, Apache loads your CGI, your
> CGI connects to the DB, then it submits the request through the the driver
> where the DB traverses its hash table to find the record, returns that data
> back through the driver interface to your CGI, then your CGI hands it back
> to Apache for delivery to the client.
> As a file, Apache just gets the file itself and returns its data to the
> client.
> On some file systems you may be able to measure a performance difference if
> your directory has more than 32l files in it, but even then it's probably
> not as much as the overhead of connecting to a DB.
> --
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting:
>  Webzine for LiveCode developers:
>  LiveCode Journal blog:

Richard, would you have the same reservations about database usage overhead
if a standalone or revlet were used as the client?  There are over 100,000
files pre-existing, so an initial creation of a server-side md5digest for
every file would be a challenge in itself.  How about a standalone which
lives on the server-side (always running - kinda cgi-like) which accepts
requests for a files md5digest and returns that string to the client
standalone/revlet before starting the download.  This is LAN based, so the
clients are few and the scope is limited, therefore malicious activity isn't
expected. But it never is, is it?  ;)


More information about the Use-livecode mailing list