Downloading a file, but checking to see if it is newer / timestamp that current?

[Justin M]

Hi there folks. I am working on a program to help teach math. Now it is a collection of tools, so instead of going around to a bunch of people to give them a new version. I was hoping I could upload the program in a ZIP file to my website. Then when they want to "update" the program can check the timestamp of the ZIP file to see if it is a more recent timestamp than the current .exe of the program they are using. If so, then download the file directly to their desktop.

I was on Google, and found this snippit of code to download a file in VB6.

Private Declare Function URLDownloadToFile Lib "urlmon" _
    Alias "URLDownloadToFileA" (ByVal pCaller As Long, _
    ByVal szURL As String, ByVal szFileName As String, _
    ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long
 
Private Sub Form_Load()
    ' Download the file.
    URLDownloadToFile 0, _
        "http://www.vb-helper.com/vbhelper_425_64.gif", _
        "C:\vbhelper_425_64.gif", 0, 0
 
    ' Display the image.
    picBanner.Picture = _
        LoadPicture("C:\vbhelper_425_64.gif")
 
    ' Size to fit.
    Me.Width = picBanner.Width + 2 * picBanner.Left + _
        (Me.Width - Me.ScaleWidth)
    Me.Height = picBanner.Height + 2 * picBanner.Left + _
        (Me.Height - Me.ScaleHeight)
End Sub

The trick is, I am not sure how to get it to check and compare a timestamp.
Would anyone know how? Thanks!

[DataMiser]

Keep in mind that the timestamp will show you when the zip file was uploaded rather than when the exe was created.
Version number is probably a better choice.

[dilettante]

Even if you made HEAD requests, the Last-Modified response header is not defined as reflecting reality, i.e. the server can reply with almost any timestamp, or omit the header entirely.

If you want to do this via HTTP, use a WebDAV server instead and implement the client side of the WebDAV protocol. WebDAV servers report accurate timestamps.

If you are stuck with a "dumb" HTTP server designed to serve web pages, then you might consider posting a second file that contains a timestamp and version number. Then you could request just those, but it means making multiple requests because there is no HTTP equivalent of "GET /ABC/*" to retrieve multiple files.

In WebDAV you can issue a single PROPFIND on a directory and get back a list of item properties (name, lastmodified, length, contenttype, etc.). Plain old Web HTTP doesn't know this method.

[SamOscarBrown]

In agreement with DM....instead of making the clients GUESS if the file they see is the 'latest', why not simply pet the version number in the title, and as far as that goes, I'd place the DTG in the name as well. Then they could check their version number (and if you had the DTG embedded somewhere visible in the program already), they could compare either the version number or the Date Time Group.

That's they way I've always seen it done in military-related applications anyway.

[dilettante]

In agreement with DM....instead of making the clients GUESS if the file they see is the 'latest', why not simply pet the version number in the title, and as far as that goes, I'd place the DTG in the name as well. Then they could check their version number (and if you had the DTG embedded somewhere visible in the program already), they could compare either the version number or the Date Time Group.

Well that sounds spiffy and all but... if the names are variable then how do you get them?

Plain Old Web HTTP has no concept of a directory request. Some servers are configured to return a default page "within the folder" (can be virtual) for some folders and an HTML "directory listing" page for others. So at best you get back a blob of HTML to parse... a blob that may change format over time as server software gets updated. This is not meant to be machine-reable information.

[SamOscarBrown]

well, dile....(and not to argue at all, but this is what I meant

"PROGRAM" name is, let's say. MYPROGRAM. And if OP zipped it up and called the zip file the same name as the program, then all his clients would know to look for MYPROGRAM.ZIP. But because just looking at that file name does not let the client know he has the latest, if OP would append the zip file name like: MYPROGRAM_V3.4.7_28Jan15.zip, then clients could check THEIR version or datetimestamp somewhere in, let's say, the Help About, and if the posted zip file is newer, then client would know to download it. That's all I was saying.
Not sure where a 'variable' program name came from.

[DataMiser]

MYPROGRAM_V3.4.7_28Jan15.zip

Would be a variable name so the client would not know what filename to ask for.
I am assuming that the intention is to automate this rather than have the user go to a web page and look for it

We do not know what options the OP has but there are a few ways to handle the task at hand.
A server side ASP script would be one method, the program could pass the current program version to the script which would then compare that to the version that is online and trigger the download if needed.

I would advise against using date time stamps as these are not reliable.

[SamOscarBrown]

Automation was NOT the impression I got:

Then when they want to "update" the program can check the timestamp of the ZIP file to see if it is a more recent timestamp than the current .exe of the program they are using. If so, then download the file directly to their desktop.

Anyway...outa here. Didn't want to get into a .....contest...was just a suggestion.

[DataMiser]

Automation was NOT the impression I got:

hen when they want to "update" the program can check the timestamp of the ZIP file to see if it is a more recent timestamp than the current .exe of the program they are using. If so, then download the file directly to their desktop.

Anyway...outa here. Didn't want to get into a .....contest...was just a suggestion.

From the bolded part in the quote above it certainly appears that the intention was to have that automated

[dilettante]

Yeah, I'm not sure how the user would know anyway. Consult another web page that lists all of the versions available on the server? And of course that still does nothing as far as an auto-updater is concernd.

Sometimes you need two version numbers you can fetch: best version and "good enough" version. If the user has "good enough" or better already then they don't have to update and the program can just say there is a newer version available and let them say "go ahead" if they want to.

Often something can change (database schema, remote web service, etc.) and this bumps the "good enough" level which all users must achieve in order to keep working at all.

[SamOscarBrown]

Ah, for the lack of (proper) punctuation!

Is it 'Then when they want to "update" the program, (indicating 'they') can check the timestamp of the ZIP', or
'Then when they want to "update", the program can check the timestamp of the ZIP.

Last comment on this thread...the Program Managers' Offices release 'new' versions of the several software applications I evaluate for the military, they post either just the latest, or the previous versionS various users can download. In messages/announcements, they simply ID which version to use (depending upon who you are). They also post the date it was posted and available for download. Our users know to check those websites to check for the latest version that might apply to them. Then, they download and install the directed one(s). Pretty straightforward, actually. That has been the SOP for the past 23 years for at least 5 major applications.