Can't handle zipped files with [, ], or ^ in the filename

[erkyrath]

You know how I said that I'd leave

await exec(`unzip -p ${zip_path} '${escape_shell_single_quoted(file_path)}' | file -i -`)

as-is until it caused a problem? It causes a problem.

In the logs, I see two examples:

Error: unzip|file error: caution: filename not matched:  platypus/options/Icon^M
Error: unzip|file error: caution: filename not matched:  4th1hrComp/agent_4F[1].A.taf

I believe both are caused by the shell getting confused by filenames.

I'm not interested in playing whack-a-mole with shell escapes. We need to use execFile().

(Reading the data and then writing it into a separate execFile('file') is okay.)

[curiousdannii]

So the reason why I was using exec rather than a series of two execFile calls here is that get_file_type could get called multiple times concurrently, which would make the logic for determining when the unzipped file can be deleted very convoluted. Or it could just unzip the file to a new temp file every request, which is also pretty gross. The current method is still unzipping the file every request, but it's at least being auto cleaned up (cause it never hits the FS.)

I've just thought of one solution: unzip and identify the mime types for all files when the zip is first downloaded, and store the results in the CacheEntry (also when restarting the server and loading cached zips.) I'd probably do it by unzipping the entire file into temp at once. Some of the comp zips are over 1GB, and I don't know what their unzipped size would be. This would make initial downloads somewhat slower. Possibly a lot slower?

Any other ideas?

[curiousdannii]

@erkyrath Do you know what zip files those errors came from?

[erkyrath]

See #42 -- there's links in a comment in there.