Check fails for s3 buckets containing files with spaces in their names

[idavidmcdonald]

I have the following resource:

- name: functional-tests-screenshots
    type: s3
    source:
      bucket: ((bucket_name))
      regexp: screenshots/(.*).png
      region_name: eu-west-2

I have the following two files in my s3 bucket

screenshots/2019-11-08-17-02-18 test_edit_and_delete_email_template.png
screenshots/2019-11-08-17-02-18_test_edit_and_delete_email_template.png

Checks fail with the following error message:

resource script '/opt/resource/check []' failed: exit status 2

stderr:
panic: version number was not valid: Expected version '2019-11-08-17-02-18 test_edit_and_delete_email_template' to match version format

goroutine 1 [running]:
github.com/concourse/s3-resource/versions.Extract(0xc0000a6140, 0x47, 0xc000086cc0, 0x14, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/go/src/github.com/concourse/s3-resource/versions/versions.go:57 +0x30c
github.com/concourse/s3-resource/versions.GetBucketFileVersions(0x9744e0, 0xc00000c5c0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, ...)
	/go/src/github.com/concourse/s3-resource/versions/versions.go:145 +0x257
github.com/concourse/s3-resource/check.(*Command).checkByRegex(0xc000183e50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, 0xc000086cc0, ...)
	/go/src/github.com/concourse/s3-resource/check/command.go:33 +0x7c
github.com/concourse/s3-resource/check.(*Command).Run(0xc000183e50, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000086ca0, 0x17, 0xc000086cc0, ...)
	/go/src/github.com/concourse/s3-resource/check/command.go:26 +0xce
main.main()
	/go/src/github.com/concourse/s3-resource/cmd/check/main.go:32 +0x1ac

If I manually delete the file with the space in the name then checks pass again.

Note, the putting of the two files was done using the s3 resource so it is just the check which fails when there is a space in the name.

Small caveat

I am actually using a fork of the s3 resource rather than the resource itself - https://github.com/alphagov/paas-s3-resource - however the check script appears to match between the two repositories so I believe this issue still stands in upstream too.