chromedriver unnecessarily unzipped on every update

[apaatsio]

It seems unnecessary that the chromedriver_xxx.zip file is unzipped on every run of webdriver-manager update.

I suggest it would skip the unzipping and setting permissions if the binary file already exists.

This problem might affect the geckodriver too, but I can't tell now because of #127

❯ ./node_modules/protractor/node_modules/webdriver-manager/bin/webdriver-manager update
webdriver-manager: using global installed version 10.2.6
[14:40:36] I/update - chromedriver: file exists /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/chromedriver_2.25linux64.zip
[14:40:36] I/update - chromedriver: unzipping chromedriver_2.25linux64.zip
[14:40:36] I/update - chromedriver: setting permissions to 0755 for /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/chromedriver_2.25
[14:40:36] I/update - chromedriver: v2.25 up to date
[14:40:36] I/update - selenium standalone: file exists /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/selenium-server-standalone-2.53.1.jar
[14:40:36] I/update - selenium standalone: v2.53.1 up to date
[14:40:38] W/file_manager - geckodriver-v0.9.0-linux64.tar.gz expected length undefined, found 1237128
[14:40:38] W/file_manager - removing file: /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.9.0-linux64.tar.gz
[14:40:38] I/downloader - geckodriver: downloading version v0.9.0
[14:40:38] I/downloader - curl -o /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.9.0-linux64.tar.gz https://github.com/mozilla/geckodriver/releases/download/v0.9.0/geckodriver-v0.9.0-linux64.tar.gz
[14:40:44] I/update - geckodriver: unzipping /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.9.0-linux64.tar.gz
[14:40:44] I/update - geckodriver: setting permissions to 0755 for /home/antti/myproject/node_modules/protractor/node_modules/webdriver-manager/selenium/geckodriver-v0.9.0

[cnishina]

I agree that this is unfortunate but there is a reason for the current setup.

Use case

A user downloads binaries with webdriver-manager update. Half way through the download, they download the file but stop it during the unzip process. When we call update again, the only check is to verify that the content-length of the binary is the same. When the user then calls webdriver-manager start, it will not work because you have a partially unzipped file or a file that does not have the correct permissions.

Alternatives with adm-zip

The alternative is to dig into adm-zip to see if we can pull out the file size and compare it to the existing file size. So we could do, is check to see if the any of the zip entries has a header of the size that matches the existing unzipped chromedriver size. I guess if we do that, then we should also find a way to check to see we do not call tar on the gecko driver file.

With adm-zip, we could possibly access the header:

let zip = new AdmZip(path.resolve(outputDir, fileName));

// could do some checking here to see if it is the first file or not by looking at the file name
// or we could loop through every entry.
let header: Buffer = zip.getEntries()[0].header;

// Set header to type any. The @types/adm-zip says that the header property is of type Buffer.
// this is to prevent error for "Property 'compressedSize' does not exist on type 'Buffer'."
//
// I'm not happy about these typings and not sure if @types/adm-zip is wrong or not but 
// to get this to transpile, setting it to any works.
let anyHeader = <any>header;

console.log(anyHeader);

{
    "made" : 788,
    "version" : 20,
    "flags" : 0,
    "method" : DEFLATED (8),
    "time" : 1230346773,
    "crc" : 0xFCBE61C,
    "compressedSize" : 3141672 bytes,
    "size" : 6932128 bytes,
    "fileNameLength" : 12,
    "extraLength" : 0 bytes,
    "commentLength" : 0 bytes,
    "diskNumStart" : 0,
    "inAttr" : 0,
    "attr" : 2179792896,
    "offset" : 0,
    "entryHeaderSize" : 58 bytes
}

The most important thing is that we are not downloading the file more than once. I'm not sure if there are a lot of benefits here. If this is an actual issue with the update functionality, we'll take a closer look.

[apaatsio]

That sounds like a feasible solution. I might give it a try in the near future unless someone does it first.