Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Attacks, FTP vs. FTPS, downloading

May
3,515
5
Rex:
Your response to my post in the TCC/LE forum explains why you don't like FTP access. Would using ftps be better to avoid/reduce attacks?

Is downloading new builds from the http site possible using TCC's IFTP and COPY commands? One of my reasons to explicitly download installers (instead of using the upgrade feature) is so I don't have to repeat it for every system, reducing my internet usage. Another (for TCC/LE only) is that I can download from TCC, without actually running LE. Last but not least, downloading from the http using most browser you need to manually specify the local target directory, or use a single shared directory for all downloads, and then move the files to wherever you want to save them. If a new build is available before I moved the previous build, I have another step to perform.

Downloading from the FTP site allows a single COPY command to download all that's newer than my last download, instead of searching the forums for announcements and compare them with my download history; etc., etc. Obviously, this is most significant when I have not had access to the JPsoft site for a more extended interval, due to vacation, travel, illness, etc. For all these reasons I hope you will continue to maintain the FTP site...
 
Is downloading new builds from the http site possible using TCC's IFTP and COPY commands?
I normally get my updates using the copy command. You can get the URL of the files from the download page. Here are some parts of my .btm for downloading. I do a gosub to these labels to download the version I want.
Code:
set DestDir=%@rtrim[\,%@path[%_batchname]]
 
...
Check args and gosub version label
...
 
:v14
set ver=v14
echo Checking %ver
gosub GetDownload "TCMD" tcmd
return
 
:v13
set ver=v13
echo Checking %ver
gosub GetDownload "TCC/LE" tccle
gosub GetDownload "TCC/LE x64" tcclex64
return

Those subroutines then call the main one to do the download/rename for the specific version.
Code:
:GetDownload [name file]
set DestFile=%[DestDir]\%[file].exe
echos Downloading %@unquotes[%name]...
copy /q http://jpsoft.com/downloads/%[ver]/%[file].exe %DestFile
iff %_? EQ 0 then
    echo done.
    iff exist %DestFile then
        set version=%@verinfo[%DestFile]
        set DestFileVer=%[DestDir]\%[file]_%[version].exe
        iff exist %DestFileVer then
            del /q /z %DestFile
            echo %@unquotes[%name] %version already downloaded
        else
            move /q /z %DestFile %DestFileVer
            iff %_? EQ 0 then
                echo %@unquotes[%name] %version downloaded (NEW)
            else
                echo Unable to rename %[file].exe to %[file]_%[version].exe
            endiff
        endiff
    endiff
else
    echo failed.
    echo Unable to download %[name] - %[file].exe
    goto end
endiff
echo.
return
 
Tim:
Thanks, your code is helpful. However, it is based on "unlimited use" internet service - you find out whether or not a file is new by downloading it first, which is exactly what I need to avoid. If I exceed 5GB in a month, my download speed is reduced to voice-line (not DSL) modem speed for the rest of the month. I had to suffer through it one month and that was more than enough...

Rex:
Would it be possible to use URLs for released versions of installers on the download page of your website that include the whole version information, as provided by @VERINFO? That would make checking whether or not it is newer than what has been already downloaded without downloading the whole file. BTW, I now own a Win7x64 system as well as two WinXPx32 systems. Downloading everything new in a single operation to the repository system is a lot more efficient than one at a time, to different systems (which is all the update option supports).
 
Would it be possible to use URLs for released versions of installers on the download page of your website that include the whole version information, as provided by @VERINFO? That would make checking whether or not it is newer than what has been already downloaded without downloading the whole file.
Having a tcmd.ver file (and equivalent for each installer .exe) in each version folder/URL would be helpful and would certainly reduce the bandwidth required to check for new versions. We could download the tiny .ver file first to check if we need to download the main installer. It would reduce server load also. ;)
 
Having a tcmd.ver file (and equivalent for each installer .exe) in each version folder/URL would be helpful and would certainly reduce the bandwidth required to check for new versions. We could download the tiny .ver file first to check if we need to download the main installer. It would reduce server load also. ;)

There's already a tiny tcmdupdate.aiu file that has all the info you need. (That's what the updater retrieves to determine if an update is available.)
 
There's already a tiny tcmdupdate.aiu file that has all the info you need. (That's what the updater retrieves to determine if an update is available.)
In that case, does the information in this other thread still apply?
 
There's already a tiny tcmdupdate.aiu file that has all the info you need. (That's what the updater retrieves to determine if an update is available.)
Cool! Thanks. In the not too distant future, I will have a bandwidth restriction similar to Steve as I go mobile and use mostly cellular data.
 
It would be nice if some entry in that file matched the @verinfo string. As it is, the @verinfo[tcmd.exe] version (14.03.59) is only included as part of some other entry text, Name, Enhancement, BugFix, etc. The ProductVersion and Version have the middle part as 0.3 instead of 03.
 
It would be nice if some entry in that file matched the @verinfo string. As it is, the @verinfo[tcmd.exe] version (14.03.59) is only included as part of some other entry text, Name, Enhancement, BugFix, etc. The ProductVersion and Version have the middle part as 0.3 instead of 03.

Can't be done; the .aiu file is generated by the installer and used by the updater, and I don't have source to either one.
 
It would be nice if some entry in that file matched the @verinfo string. As it is, the @verinfo[tcmd.exe] version (14.03.59) is only included as part of some other entry text, Name, Enhancement, BugFix, etc. The ProductVersion and Version have the middle part as 0.3 instead of 03.

If all you want to do is check for a new version you don't need to parse the contents of the file - just keep a local copy and compare its MD5 hash with the file on the server and you'll know when there's an update available.
 
Why can't you just run the check for updates dialog without doing a download? If there is a newer version available then do whatever it is you do.
 
If all you want to do is check for a new version you don't need to parse the contents of the file - just keep a local copy and compare its MD5 hash with the file on the server and you'll know when there's an update available.
I keep multiple installer versions and check whether I have a specific version of the installer file. If the @verinfo is always the last word of Name, I can get that easily enough.
 
Steve,

Here is an update for you:
Code:
:GetDownload [name file]
set download=N
gosub CheckVersion %name %file
iff %download EQ Y then
...
endiff
return
 
:CheckVersion [name file]
echos Checking latest %@unquotes[%name] version...
set VerDestFile=%[DestDir]\%[ver]_%[file]update.aiu
copy /q /z http://jpsoft.com/downloads/%[ver]/%[file]update.aiu %VerDestFile
iff %_? EQ 0 then
    echo done.
    set version=%@word[-0,%@iniread[%[VerDestFile],Update,Name]]
    iff exist %[file]_%[version].exe then
        echo %@unquotes[%name] %version already downloaded
    else
        set download=Y
    endiff
else
    echo failed.
    goto end
endiff
return
 
Why can't you just run the check for updates dialog without doing a download? If there is a newer version available then do whatever it is you do.
It is save bandwidth when upgrading more than one machine. If you keep a copy of the installer, you can just copy to another machine instead of downloading it again.
 
It is save bandwidth when upgrading more than one machine. If you keep a copy of the installer, you can just copy to another machine instead of downloading it again.
Steve mentioned his 5GB bandwidth limit. In the next month or two, I hope to start living full-time in our RV and will be using cellular data for my internet access since RV park wifi is notoriously slow. I can get 4GB via my A&T iPhone and 10GB via Verizon MiFi. The Coverage? iOS app will help me find higher speeds, but my limits are a bit fixed. I certainly will not have unlimited bandwidth like I do now with cable internet.
 
BTW, I now own a Win7x64 system as well as two WinXPx32 systems. Downloading everything new in a single operation to the repository system is a lot more efficient than one at a time, to different systems (which is all the update option supports).

Not that much -- you'll still need a TCMDx64 and a TCMDx86, so you'll need two downloads, not one.
 
Steve mentioned his 5GB bandwidth limit. In the next month or two, I hope to start living full-time in our RV and will be using cellular data for my internet access since RV park wifi is notoriously slow. I can get 4GB via my A&T iPhone and 10GB via Verizon MiFi. The Coverage? iOS app will help me find higher speeds, but my limits are a bit fixed. I certainly will not have unlimited bandwidth like I do now with cable internet.

I've been using 3G (and now 4G) for the past couple of years. There is no cable or fiber within 15 miles of my home, and I suspect I'm uploading & downloading a whole lot more! :D
 
2 questions:

1. Is this syntax ok for "generating" my actual version according to the format in the .aiu file?
Code:
(system)  C:\...\TCMD14x64 >ver
 
TCC  14.03.52 x64  Windows 7 [Version 6.1.7601]
 
(system)  C:\...\TCMD14x64 >echo %_vermajor.%@if[%_verminor = 0,%_verminor,0.%_verminor].%_build
14.0.3.52
2. If I compare the version of the actual .aiu file with my above generated,
Code:
(system)  C:\...\TCMD14x64 >copy http://jpsoft.com/downloads/v14/tcmdx64update.aiu
http://jpsoft.com/downloads/v14/tcmdx64update.aiu => C:\Program Files\JPSoft\TCMD14x64\tcmdx64update.aiu
     1 file copied
 
(system)  C:\...\TCMD14x64 >echo %@iniread[.\tcmdx64update.aiu,update,version]
14.0.3.59
there seems to be a newer version available.
But if I do an option /u I get "your software is up to date".
 
I've been using 3G (and now 4G) for the past couple of years. There is no cable or fiber within 15 miles of my home, and I suspect I'm uploading & downloading a whole lot more! :D
Perhaps, but perhaps not. I have been working remotely for over 4.5 years as part of a team supporting a very large factory automation environment for a global corporation and its customers. The vast majority of my development work is done on my laptop using team tools like Clearcase, Lotus Notes, Sharepoint, etc. Since I am only one part of one of the teams, but have interactions with others, I also receive/download a lot of changes made by others. I try to do my testing locally, but my production/test environment is on a set of ESXI/VMs accessed over VPN, which means I need to upload the binaries frequently during the test/fix cycles. It then get's really bad when they branch a new version and I need to download the new project/version branch folders, just one of which approaches 1GB in version controlled source files. It is almost entirely downloaded over VPN as I am rarely in the office. ;)

I'm not complaining, mind you. I love working remotely. My bandwidth will just be more constrained in the future. I did a test of my usage over the year end holidays. In the two weeks of three days each, I used 3.5GB of my 4GB AT&T plan. Eliminating my part-time use of Pandora will help some, but not entirely. I'm hoping the 14GB of my combined Verizon and AT&T plans are sufficient, but am not 100% sure of that.
 
<<snip>>

(system) C:\...\TCMD14x64 >ver

TCC 14.03.52 x64 Windows 7 [Version 6.1.7601]
<<snip>>

But if I do an option /u I get "your software is up to date".

There's something odd there Frank, Build 59 was released in Jan 2013, so you should see that an update is available. On my system the first two lines output by ver /r are:

TCC 14.03.59 x64 Windows 7 [Version 6.1.7601]
TCC Build 59 Windows 7 Build 7601 Service Pack 1

Dan
 

Similar threads

Back
Top