Windows - Fix relative paths in app.zip

[Rigby90]

After changes by @chrishardinge and I believe yourselves on the Vapor Core 2.0 branch (exposing PHP Error's) I started receiving PHP/Composer errors within AWS deployments from Windows.

The runtime/app is unable to load the composer dependencies, I'm assuming as it extracts the files incorrectly due to their relative paths being different/invalid for Linux when compiled/zipped under Windows as seen below -

Windows app.zip

~/vapor-test/vapor-test$ zipinfo windows.zip "*autoload*"                                                                                                                 -r--r--r--  6.3 unx      178 b- defX 19-Sep-16 16:31 vendor\autoload.php
-r--r--r--  6.3 unx   408342 b- defX 19-Sep-16 16:31 vendor\composer\autoload_classmap.php
-r--r--r--  6.3 unx     2984 b- defX 19-Sep-16 16:31 vendor\composer\autoload_files.php
-r--r--r--  6.3 unx      278 b- defX 19-Sep-16 16:31 vendor\composer\autoload_namespaces.php
-r--r--r--  6.3 unx     4887 b- defX 19-Sep-16 16:31 vendor\composer\autoload_psr4.php
-r--r--r--  6.3 unx     2103 b- defX 19-Sep-16 16:31 vendor\composer\autoload_real.php
-r--r--r--  6.3 unx   452425 b- defX 19-Sep-16 16:31 vendor\composer\autoload_static.php
-r--r--r--  6.3 unx     1001 b- defX 19-Sep-16 16:31 vendor\opis\closure\autoload.php
-r--r--r--  6.3 unx      231 b- defX 19-Sep-16 16:31 vendor\paragonie\random_compat\psalm-autoload.php

WSL app.zip

~/vapor-test/vapor-test$ zipinfo wsl.zip "*autoload*"                                                                                                                     -r--r--r--  6.3 unx     1001 b- defX 19-Sep-16 17:00 vendor/opis/closure/autoload.php
-r--r--r--  6.3 unx      178 b- defX 19-Sep-16 17:00 vendor/autoload.php
-r--r--r--  6.3 unx     2984 b- defX 19-Sep-16 17:00 vendor/composer/autoload_files.php
-r--r--r--  6.3 unx     2103 b- defX 19-Sep-16 17:00 vendor/composer/autoload_real.php
-r--r--r--  6.3 unx   408342 b- defX 19-Sep-16 17:00 vendor/composer/autoload_classmap.php
-r--r--r--  6.3 unx   452425 b- defX 19-Sep-16 17:00 vendor/composer/autoload_static.php
-r--r--r--  6.3 unx     4887 b- defX 19-Sep-16 17:00 vendor/composer/autoload_psr4.php
-r--r--r--  6.3 unx      278 b- defX 19-Sep-16 17:00 vendor/composer/autoload_namespaces.php
-r--r--r--  6.3 unx      231 b- defX 19-Sep-16 17:00 vendor/paragonie/random_compat/psalm-autoload.php

@chrishardinge - Hopefully you can check this over and confirm it works for yourself under windows as well. However for myself, the attached changes allow me to run vapor deployments under windows - https://windows.simonrigby.dev/ , I'm no longer receiving a 502 Gateway Timeout error when visiting the page, both using the domain and vanity url.

[monsterdream]

Bingo! That solved issues for me!

[chrishardinge]

Excellent find, @Rigby90 !
That explains why my file comparison of the extracted archives matched. 😅
Lambda might be extracting files such as vendor/composer/autoload_files.php, and reading it as a filename, rather than a file two sub-directories deep.
I'll give this a test soon, but it looks good!

[Rigby90]

@chrishardinge

That explains why my file comparison of the extracted archives matched. 😅

Exactly, same here, I was too focused on the contents and permissions of the files within the ZIP and not the structure.

Apart from this, the only other difference I've spotted between the two deployments (Windows vs WSL/Linux) is that the Windows JSON payloads also uses a backwards slash when referencing the assets, however in this instance it is escaped so does not appear to be causing a problem.

WSL -

{
	"files": [{
			"path": "css\/app.css",
			"hash": "d41d8cd98f00b204e9800998ecf8427e"
		}, {
			"path": "favicon.ico",
			"hash": "d41d8cd98f00b204e9800998ecf8427e"
		}, {
			"path": "js\/app.js",
			"hash": "859cf19933cad91012d196fd48cffc9c"
		}, {
			"path": "robots.txt",
			"hash": "b6216d61c03e6ce0c9aea6ca7808f7ca"
		}
	]
}

Windows -

{
	"files": [{
			"path": "css\\app.css",
			"hash": "d41d8cd98f00b204e9800998ecf8427e"
		}, {
			"path": "favicon.ico",
			"hash": "d41d8cd98f00b204e9800998ecf8427e"
		}, {
			"path": "js\\app.js",
			"hash": "859cf19933cad91012d196fd48cffc9c"
		}, {
			"path": "robots.txt",
			"hash": "b6216d61c03e6ce0c9aea6ca7808f7ca"
		}
	]
}

Hoping this is the last of the Windows related issues as I'm looking forward to moving forwards and deploying with Vapor.