felddy/foundryvtt-docker

Install Breaks when Admin provides Windows Install URL causing container to store the exe file in cache as zip file blocking further start after putting the correct Linux NODE URL.

fastalan opened this issue · 3 comments

fastalan commented

Bug description

The container stores the windows installer as the same filename as the linux nodeJS zip file in cache and prevents container from starting even when the url is corrected.

Steps to reproduce

Start the container with FOUNDRY_RELEASE_URL set to a windows EXE download
Container start will fail with error that its a windows file
Set the FOUNDRY_RELEASE_URL to a correct Linux NodeJS zip file
Start the container, note the same windows file error
Log shows:
Entrypoint | 2023-11-19 22:59:55 | [error] The release file appears to be a Windows executable (.exe).
Entrypoint | 2023-11-19 22:59:55 | [error] Please provide the 'Linux/NodeJS' version of the release or URL.

Expected behavior

I expect the container not to store the incorrect downloaded file as the zip file. It should error out and not store the file in cache.

Container metadata

Not applicable
felddy/foundryvtt:11.315.0

Relevant log output

Entrypoint | 2023-11-19 22:59:55 | [error] The release file appears to be a Windows executable (.exe).
Entrypoint | 2023-11-19 22:59:55 | [error] Please provide the 'Linux/NodeJS' version of the release or URL.

Code of Conduct

  • I agree to follow this project's Code of Conduct
felddy commented

Yes. This is indeed not the correct behavior. When I get a chance I'll create a patch. Thank you for running this down and reporting it.

See also:

fastalan commented

I found the issue, it's in entrypoint.sh. The file is downloaded and saved as a zip no matter what. The original filename from the foundry aws server should be preserved, also the file type checks should take place after download, if the file is not of the correct type it could be deleted from the cache.
`
set +o nounset
downloading_filename="${CONTAINER_CACHE%%+(/)}${CONTAINER_CACHE:+/}downloading.zip"
release_filename="${CONTAINER_CACHE%%+(/)}${CONTAINER_CACHE:+/}foundryvtt-${FOUNDRY_VERSION}.zip"
set -o nounset

if [[ "${s3_url:-}" ]]; then
log "Downloading Foundry Virtual Tabletop release."
# Download release if newer than cached version.
# Filter out warnings about bad date formats if the file is missing.
curl ${CONTAINER_VERBOSE+--verbose} --fail --location
--user-agent "${curl_user_agent}"
--time-cond "${release_filename}"
--output "${downloading_filename}" "${s3_url}" 2>&1
| tr "\r" "\n"
| sed --unbuffered '/^Warning: .* date/d'

# Rename the download now that it is completed.
# If we had a cache hit, the file is already renamed.
**mv "${downloading_filename}" "${release_filename}" > /dev/null 2>&1 || true**

fi
`

felddy commented

I've created a PR to fix this issue:

If you are inclined to test this out you can pull the image felddy/foundryvtt:bugfix-843. I'll probably merge it in tomorrow unless we discover any issues.

Additionally I've opened an issue in the FoundryVTT repo requesting the download page make it more obvious what OS version is selected: