shawn

@floele, can we get a tab to that page added to the forum? I tried to find the link the other day and just couldn't find it.

+1

+1

@soeka the log you posted and the config you posted are not the same. There's no way that the config you shared ("Mikrotik ARM (all)") would get that file, since it never references the Bugfix folder. Most likely there is an issue with your "bugfix" config and that's the one that's having problems. I suspect that the folder "D:\Unduhan\Jaringan\Mikrotik\Bugfix" just needs to be created so that Ketarin can write your file to it.

"version":"([\d\.+])"

Most commonly this problem happens in either of these situations: 1) The destination drive letter has changed (such as a removable device that is no longer the original drive letter). Are you still downloading to the D: drive? That is, does "{path-download}" still reference "D:\Unduhan" and not something different like "J:\Unduhan" or "D:\Unduhan\" (note the trailing slash)? 2) The hash is invalid. This could be from added spaces, tabs, or other invalid characters that are being collected incorrectly. It's also possible that since you're not using capture that this could be the problem. Use this instead: (?<={url:filename}: )([a-z0-9]{64})

it's bad form within the URI specification, but it's an edge case so browsers will usually allow it anyway. this is "HTML-encoded" (uses an ampersand escape) not "URL-encoded" (uses a percentage escape). URI's are supposed to be encoded with URL-encoding. in situations like these I would recommend you pre-parse the URL by performing a replacement operation on it. {url:replace:&#43;:+} Alternatively, you could pass it to multireplace to swap out a series of broken encodings like this (or any other string selections you wanted to replace).

is there a reason why you're using int instead of datetime? i can't imagine it would be anywhere near as useful as an integer.

The error suggests that the field isn't really a timestamp or date field, but is being using an epoch or something instead. @floele what's the field structure of the CreatedAt column? If you'd like to take this offline you can email me.

This is a @crrodriguez thing. The database needs to be modified to add NOW() or CURRENT_TIMESTAMP as the default value for the `CreatedAt` field. ALTER TABLE `apps_applicationjobs` CHANGE `CreatedAt` `CreatedAt` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ;

are you getting an error in the log?

fantastic, @floele! thank you!

that's a great idea, @floele. I think the "!" identifier would be a great inclusion. tying it to pre-check would probably also work, but would be messier.

This is not the first time and won't be the last time. Because of that, this is actually one of those that I dig thru the FTP server to find direct links to. Adobe does a horrible job of making this easy. Step one is to parse this page for the espoused version of the current release notes (parse for DC/continuous[^()]+?\(([\d\.]+x?)\) ): https://helpx.adobe.com/acrobat/release-note/release-notes-acrobat-reader.html Step two is to use that to pull the folder from here, replacing all the periods with nothing and the the x with \d to perform a regex match as "versionshort": ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/ Step three is to parse for either the msp (update file) or the exe (installer) from here, where the language is one of de_DE, en_US, es_ES, fr_FR or ja_JP, and the msp you want is the one without an underscore ("Acr[^\_\s\r\n\t]+msp") unless you're using a non-standard language, then you need both msp's: ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/{versionshort}/ Download them using this URL pattern: https://download.adobe.com/pub/adobe/reader/mac/AcrobatDC/{versionshort}/{filename} Here's the rub. The worst part in this entire process is that FTP servers can't be handled directly within Ketarin parsing routines, so I had to setup an HTTP to FTP gateway on one of my servers to return the results as text so this information can be parsed -- and that's why I'm not just sharing an app xml with everyone. The FTP gateway is just a PHP file that converts various input parameters to an FTP request using standard PHP functions. If I were to share this then my server would quickly be abused as an FTP gateway for all sorts of evil, and that's just not going to happen. Here's the PHP file I'm using for this: <?php header("Content-Type: text/plain"); $server = $_GET["s"]; if($server==""){die();} $port = $_GET["p"]; if($port==""){$port = 21;} //$port = intval($port); $dir = $_GET["d"]; if($dir==""){$dir = "/";} // connect $ftp = ftp_connect( $server, $port ); if (!$ftp) die('could not connect.'); //echo("cnx ok\n"); // login $res = ftp_login( $ftp, "anonymous", "" ); if (!$res) die('could not login.'); //echo("login ok\n"); // enter passive mode $res = ftp_pasv( $ftp, true ); if (!$res) die('could not enable passive mode.'); //echo("pasv ok\n"); // get listing $res = ftp_chdir( $ftp, $dir ); // change directory //$res = ftp_nlist($ftp, '-a'); // simple file listing $res = ftp_rawlist( $ftp, '-a'); if(is_null($res)){ $res = ftp_rawlist( $ftp, "." ); } //echo($res); echo(implode("\r\n", $res)); //print_r($res); //var_dump($res); A gated request to the first file would look like this: https://example.com/myftpgateway.php?s=ftp.adobe.com&d=/pub/adobe/reader/win/AcrobatDC/&p=21 And the versioned request would look like this: https://example.com/myftpgateway.php?s=ftp.adobe.com&d=/pub/adobe/reader/win/AcrobatDC/{versionshort}/&p=21 The output is simple text (which may look funky in a browser but will parse fine by Ketarin). It would look something like this: drwxrwxr-x 29 ftp ftp 750 Feb 12 11:49 . drwxrwxr-x 16 ftp ftp 332 Feb 07 07:05 .. drwxrwxr-x 2 ftp ftp 2583 Apr 06 2015 1500720033 drwxrwxr-x 2 ftp ftp 327 Jul 14 2015 1500820082 drwxrwxr-x 2 ftp ftp 429 Oct 13 2015 1500920069 drwxrwxr-x 2 ftp ftp 194 Oct 29 2015 1500920077 drwxrwxr-x 2 ftp ftp 194 Nov 25 2015 1500920079 drwxrwxr-x 2 ftp ftp 429 Jan 12 2016 1501020056 drwxrwxr-x 2 ftp ftp 194 Feb 16 2016 1501020059 drwxrwxr-x 2 ftp ftp 429 Mar 08 2016 1501020060 drwxrwxr-x 2 ftp ftp 429 May 10 2016 1501620039 drwxrwxr-x 2 ftp ftp 194 May 19 2016 1501620041 drwxrwxr-x 2 ftp ftp 194 Jun 02 2016 1501620045 drwxrwxr-x 2 ftp ftp 327 Jul 12 2016 1501720050 drwxrwxr-x 2 ftp ftp 92 Aug 02 2016 1501720053 drwxrwxr-x 2 ftp ftp 327 Oct 11 2016 1502020039 drwxrwxr-x 2 ftp ftp 92 Nov 03 2016 1502020042 drwxrwxr-x 2 ftp ftp 327 Jan 10 2017 1502320053 drwxrwxr-x 2 ftp ftp 92 Jan 19 2017 1502320056 drwxrwxr-x 2 ftp ftp 327 Feb 21 2017 1502320070 drwxrwxr-x 2 ftp ftp 327 Apr 11 2017 1700920044 drwxrwxr-x 2 ftp ftp 92 Jul 11 2017 1700920058 drwxrwxr-x 2 ftp ftp 327 Aug 08 2017 1701220093 drwxrwxr-x 2 ftp ftp 92 Aug 11 2017 1701220095 drwxrwxr-x 2 ftp ftp 92 Aug 29 04:58 1701220098 drwxrwxr-x 2 ftp ftp 327 Nov 14 05:53 1800920044 drwxrwxr-x 2 ftp ftp 92 Nov 29 11:23 1800920050 drwxrwxr-x 2 ftp ftp 327 Feb 12 11:34 1801120036 drwxrwxr-x 2 ftp ftp 183 Jul 14 2015 misc That's why you're parsing for "18.011.2003x" and changing it to a regex for "180112003\d". Good luck!

for your specific example, you would be better off ignoring the "delete previous file" setting and using a generic download name instead. On the Application tab, in the Download Location field, make sure the option is set to "Save to File" (not "Save in Folder") and use this value: {root}GEGeek_Toolkit\ProgramFiles\{category}\7z x64\7z_x64.exe This skips the actual issue with your profile, which is that you're changing the filename after the download to a generic installation package name. Sure, it's being done as part of the post-commands, but it still changes the file name from what was downloaded.

It only deletes the previous file if it was created/downloaded with Ketarin. If you've renamed the file then it won't delete the previous file. It only deleted the previous file if the path is EXACTLY the same as it was when it was downloaded (for example, the drive name can't change). If you've changed/replaced the app profile (in other words, it's not the same as the one that actually downloaded the file) then it won't delete the previous file, because the reference to the previous file doesn't exist. To find out for sure whether a file will be deleted select the app profile in the main Ketarin window, CTRL+C, then paste it into notepad. Look for the "PreviousLocation" value. If this value is populated, then that is the file that will be deleted. If it's NOT populated, then it won't delete anything.

did you try the registry changes that have been suggested to you twice now?

glad to hear you got it sorted

the problem appears to be that the initial TLS/SSL handshake is not negotiating for TLS 1.2, which is (was?) the default behavior in most Microsoft apps. It looks like this explains the problem well and how to work around it.

Did you try the registry hack from here, yet?

@Rainie please go to https://ketarin.org/forum/settings/ and enter the GUID from the "Author" field in the image above. This is a required step in uploading to the online database. You should also check the online database to ensure that none of the existing Applications use the exact same name as your app, and that you actually created the app profile locally and did not modify an existing one. If you did not create it then the 'Guid' field (if you copy it) will not be unique to your app profile either, and will need to be modified/recreated so yours will sync.

thanks, Floele!

and yes, that's what's going on, they're blocking all secure connections other than TLS 1.2

My guess is that they're blocking anything other than TLS 1.2, which seems to be a growing problem. You can try the registry hack from here, but be aware that it can affect other .NET apps on your computer as well.

thank you for sharing, @herbert2 ! be aware that this change affects every .net application on your system, including Office 365, some application updaters and more. while it's a good security fix to employ in a general sense, some third-party stuff doesn't behave with strong security, so this change can break certain apps that communicate with sites that don't support TLS 1.2