Jump to content
Ketarin forum

Bug or Design?


appyface
 Share

Recommended Posts

I hope I can explain clearly...

 

Ketarin is downloading Orbit for me. The URL for download is static one, the download name does not include any version info:

http://dl.orbitdownloader.com/dl/OrbitDownloaderSetup.exe

 

As many of us do, I put the version number I scrape from a page in the site, on the download filename:

d:\stuff\filestore\iutils\{url:basefile}_{vers}.{url:ext}

 

Until today's Ketarin run, the version scraped was 2.8.3 so my download filename was this:

D:\Stuff\filestore\IUtils\OrbitDownloaderSetup_2.8.3.exe

 

Today I run Ketarin and it downloaded a new file, because (from log) the file sizes did not match. My new download is still

D:\Stuff\filestore\IUtils\OrbitDownloaderSetup_2.8.3.exe

 

I check the webpage I'm scraping for {vers} and sure enough the version number is still 2.8.3 there. I check another page in the site and it has been updated, version is 2.8.4.

 

So. I edit the app in Ketarin and change my {vers} variable scrape to use the webpage with 2.8.4 on it.

 

Next I issue CTRL-U on the Orbit app, and I see the {vers} variable contents were changed (vers is displayed in my custom column). But Ketarin did not download and create a new filename of

D:\Stuff\filestore\IUtils\OrbitDownloaderSetup_2.8.4.exe

 

as I had expected? That filename doesn't yet exist... but it appears Ketarin didn't check for existence of downloaded filename? (Note I do not have the option "delete previous downloaded file" selected as I want to keep these versions.)

 

2/4/2009 5:35:38 AM: Update started with 1 application(s)

2/4/2009 5:35:39 AM: Replacing {vers} in 'd:\stuff\filestore\iutils\OrbitDownloaderSetup_{vers}.exe' with '2.8.4'

2/4/2009 5:35:39 AM: Orbit Downloader: Checking if update is required...

2/4/2009 5:35:39 AM: Orbit Downloader: Update not required

2/4/2009 5:35:39 AM: Update finished

 

 

Bug or design? I do recall some posts here asking for Ketarin to not download again after a file has been renamed... Was that implemented? Is it user-switchable per app if so? In my case I would like Ketarin to download it again after I have caused a change to the disk filename...

 

Thoughts?

 

Thanks as always,

--appyface

Link to comment
Share on other sites

Though it probably makes sense to disable that behaviour if the "delete previous" option is not checked.
Flo.. I agree that this behavior is undesirable for my use of Ketarin as I NEVER 'delete previous version' due to the fact that I archive ALL app versions (newer is not always better, except in Ketarin). ;) As a result, I have quite a few apps that have been updated while the version appended to the file name remained the same resulting in erroneous file names... (version name appended and actual file version don't match). If there is any way to correct this SOON... I'm all for it ! :D
Link to comment
Share on other sites

@CybTekSol

 

Not sure how my case differs from you, but my previous disk file of 2.8.3 is really 2.8.4, in this situation I've lost the real version 2.8.3.

 

Not Ketarin's fault of course, Ketarin had no way of knowing that my variable scrape unfortunately was still grabbing 2.8.3 even though it was a new file.

 

Once I changed the variable to 2.8.4, yes I'd like Ketarin to redownload the file to that name, even though I already have the identical file with 2.8.3 for the name. But Ketarin still can't help me that my real 2.8.3 version is gone -- I'm just going to have to get it from the site and/or backups if I need it.

 

Like regex and everything else, we're at the mercy of the website. One thing that WOULD stop Ketarin from overwriting a current version with a new one, when the vers variable scrape did not change, is to put that vers variable into the special parameter that tells Ketarin NOT to consider it updated if this variable has not changed.

 

Then if my webpage guy ever got around to fixing it and making it say version 2.8.4, Ketarin would then download the new file.

 

Another reason independent verification (with page watching service, the Ketarin feature I proposed, whatever) is also very important. Can't know what you can't know, if you know what I mean? Ya know? :) :) :)

 

--appyface

Edited by appyface
Link to comment
Share on other sites

How about a 'Archive before update' feature that would NEVER overwrite the archived version if it is the same version as named? This would probably solve my problem. This could be possibly be accomplished with a move command if the command could be set to execute BEFORE retrieving an update. What do you think Flo?

Link to comment
Share on other sites

I know you asked Flo :) but that's in essence what the special variable does. That variable guarantees as as long as the contents of it have not changed, Ketarin will not download a new file for any reason.

 

Do you envision your idea working differently from this? If you can elaborate some examples...

Link to comment
Share on other sites

I know you asked Flo :) but that's in essence what the special variable does. That variable guarantees as as long as the contents of it have not changed, Ketarin will not download a new file for any reason.

 

Do you envision your idea working differently from this?

I believe the 'special variable' you suggested would work for me... I don't know which method would be easier to achieve from Flo's perspective. I'm open to any method that works reliably! ;)
Link to comment
Share on other sites

If Flo goes has Ketarin write a new filename anytime the filename does not exist (and delete old versions is not selected), that will take care of getting a new file on disk even though the same file was written already to another name.

 

Then, for those disk files where we simply cannot put up with accidentally overwriting the previous version name with the new program, we can use the special variable (edit the app, it's on the 'advanced' tab, at the bottom).

 

The special variable works very well, I've been using it with a particular program that the author (for reason still unknown to me) keeps updating the file dates on, even though the program itself has not been updated. Without this special variable, Ketarin would see the new dates every few days and redownload the same file.

Link to comment
Share on other sites

The special variable works very well, I've been using it with a particular program that the author (for reason still unknown to me) keeps updating the file dates on, even though the program itself has not been updated. Without this special variable, Ketarin would see the new dates every few days and redownload the same file.
appyface,

Could you please describe exactly how you have implemented this 'special variable' as I am not sure I fully understand what you are doing?

Link to comment
Share on other sites

Sure!

 

Define a variable (I scrape from webpage, but I believe almost any variable will work.)

 

You put the variable on the 'advanced' tab in the setup for app.

 

Here's how it works: This variable alone controls Ketarin's downloading. If the contents of this variable change, you want Ketarin to download the file. If the contents have not changed, Ketarin does not download the file, ignoring any other indications that it should download the file.

 

This feature was originally intended to stop the periodic repeat downloading of the same exact file, because some other indicator such as the file dates on the server, had been changed.

 

I do have a couple of apps like that. For whatever reason the file dates on the server change every few days, but the app has not been updated. Every time the file dates changed, Ketarin downloaded the file again, until I put the special variable in. I use version scraped from a page as my indicator -- if the scraped version number changes, Ketarin should get the file. Otherwise, no.

 

(The only reason I didn't like the re-downloading is because it tricked me into thinking there was a new version available, but there wasn't.)

 

So. We can use this special variable to protect against the accidental overwriting of a previous version too, when that variable is part of the disk file name like mine was.

 

My version scrape was still 2.8.3 in this case. Had I been using this for the special variable, Ketarin would not have downloaded the new file (which is really 2.8.4). But I was not using the special variable, so Ketarin rightly detected that a new file was available, and faithfully wrote it to the disk name I specified, which still had 2.8.3 in the name.

 

By not using the special variable to stop Ketarin from downloading, I lost my 2.8.3 version file. Ketarin overwrote it with the newer 2.8.4 version of the file.

 

Then, the second part of this is what I started this thread for. Once I realized my version variable was not correct, I did change the scrape so my version variable was now coming in as 2.8.4. Ketarin had already downloaded that file, so there was nothing new to download, and it did not check further to see if the filename existed (it did not).

 

Hope that helps. Let me know?

--appyface

Edited by appyface
Link to comment
Share on other sites

I'm so sorry, I'm failing to understand where your confusion is? Around what point(s)? Are you asking about the specific case I've already illustrated here in this thread? I've already stated I'm scraping a version number from a webpage... so I don't understand what part your question refers to. Throw me a bone? :)

Link to comment
Share on other sites

@appyface,

I apologize... I apparently was just confused regarding the term 'special variable' as it led me to believe you were 'scraping' another variable in addition to {version} as a 'change indicator'. So you were ONLY referring to {version} as the 'change indicator variable' on the 'advanced settings' tab ALONE? I thought you may have stumbled upon something that I had not discovered yet, such as a way to define and combine the version variable with anotheras the 'change indicator'. Just wanted to make sure I had not been left in the dark regarding a 'hidden' easter egg! That's the only bone I can throw. ;) In my defense for not completely understanding this, I've been on a system build blitz of late... about a 100 hours in the last week. :(

Edited by CybTekSol
Link to comment
Share on other sites

@CybTekSol

 

No worries, it's all good :) I'm sorry for your long hours, though...

 

Well. You are right, I used to have an app entry using something other than 'vers' for a CIV (hey I just made that up: Change Indicator Variable). I don't do this any longer. But at the time it served me well, however funky :)

 

The only requirement for the CIV, of course, is that it has meaning to YOU with respect to controlling whether Ketarin downloads (or not). Using the CIV to watch for something other than version number or 'changed on' date for versionless apps, is likely to be rare or even non-existent. After all, the whole idea behind Ketarin is to watch for and download new app versions :)

 

Still, consider this scenario. As stated above, I don't do this any longer, thanks to Ketarin's continual improvement to provide simplified but accurate notifications of new app versions.

 

  1. The app's website offers the currently released, public version app URL. (Similar to Ketarin's URL on Ketarin's official website, which downloads new Ketarin version only when it is publicly released.)
     
  2. The app's website also offers development builds of this app from time to time, URLs are located in another place on the site.
     
  3. The app's 'dev build' page offers a unique URL when there is a new dev build (contains the version and build info). I used a regex to scrape that URL into a variable for Ketarin to download from. Nothing unusual there.
     
  4. When the current dev cycle ends, and the last dev build becomes the current public release, unfortunately the last dev build URL remains on the dev build page. (Would be simpler if it didn't.) However, the author was very consistent in throwing an '*' on the page when this happened, pointing out a footnote such as, "The current development cycle has ended, the last development build has been released" or similar. The consistent appearance of the '*' character formed the basis for the CIV 'trick' I had employed!
     

Forgetting the presence of the CIV for a moment, the dev build is a fairly typical Ketarin entry, very similar to the one I have for the released version of the app.

 

Now recall from item #4 above, the last dev build URL will remain unchanged and be scraped 'forever' once it has gone to released status, or until the next dev build URL is posted. Ketarin will correctly avoid downloading from this URL whenever it has not changed.

 

Those two Ketarin entries (one for released app, one for dev build of app) ought to be enough to visually indicate when the released app is new and the dev build is not. Should have no need of a CIV variable, right? Keep in mind, I established the following somewhat quirky CIV 'scheme', back when all of Ketarin's visual status icons would reset with the next Ketarin command (they don't any longer, in most cases, which is very helpful).

 

I didn't always make a note of all that had been updated or was not updated, before I lost the icons. Sure I could use the log view, or I could use something like the nice text listing presented by mazzthepianoman here:

http://ketarin.canneverbe.com/forum/viewtopic.php?id=93 to give me this info. But I preferred that Ketarin should hit me with a 2x4 if the dev build became released, instead. :)

 

  1. As already mentioned, for the dev build download, I scraped the changing-until-released unique download URL, which already contained the dev build version info in the URL and downloaded filename.
     
  2. My CIV variable was made up of a concatenation of a bit of text (more on that in a bit) and the current dev build's version which I scraped from the same unique download URL. Recall that the presence of a CIV controls all downloading. I needed to ensure the CIV would change whenever a new dev build was released, so I would always get the new download.
     
  3. I also used this same CIV variable in the output disk filename for the dev build. The use of the CIV in the disk filename was completely redundant, as the URL provided a disk file name with the current dev build versioning. But herein lies the 'trick' -- the little bit of text concatenated into the CIV variable with the versioning.
     

Thanks to the consistency of the website author in always adding an '*' to some otherwise static text, if the dev build became released, I was able to use this to my advantage. Normally the little bit of text was static, so it was the version number in the CIV that had to change, to get me the dev build download.

 

But when the author released the latest dev build, the dev build version number remained the same. But I'd get an '*' included with the little bit if text part of the CIV. So again the CIV had changed, telling Ketarin to try to download.

 

If you know your Windows filesystem constructs, then you know that an '*' character is illegal in a disk filename. When the dev build went released, the CIV (which was part of the disk filename) suddenly contained an '*', which forced Ketarin to throw me an error dialog, aka a 2x4 that the dev build had been released.

 

How's that for funky? LOL

 

Sorry for a long long post, CybTekSol! If you have the time to go step-by-step and visualize the pieces as they are presented, you will understand how the CIV could be tricked into giving me the notification I desired.

 

I do believe the CIV will end up with only two real uses, and it will contain only version related info (version number or changed-on date, as examples). Other peculiar uses like the example I give here, will not be necessary because there are easier ways to get what you need, now.

 

  1. To stop Ketarin from showing 'false positives'. Use of the CIV will prevent Ketarin from repeated downloading of the same app version, whenever other (erroneous) indications of update are present (such as a change in the file dates on the server)
     
  2. To prevent unintended loss of previous version disk file. Use of the CIV, when the CIV is also part of the disk file name, will prevent Ketarin from overwriting an old disk file (versioned) name with different app contents.
     

 

I hope this long post is not overwhelming and is helpful! However weird :)

 

Best,

--appyface

 

P.S. @Flo -- I do still look forward to a change to Ketarin, for the issue that precipitated this thread. When the CIV is not being used, and 'delete prior versions' is not enabled, for Ketarin to detect when the current disk filename does not exist, and to download the same app version again.

Edited by appyface
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.