When verifying #881, I mistakenly thought I was supposed to set my $ZAR_ROOT to an actual S3 URL, but this is incorrect. I was supposed to still use a $ZAR_ROOT on the local filesystem and specify the S3 URL via -data.
When I did it the wrong way, it actually accepted this and populated the bucket, but put the metadata in a local path starting with a directory s3:. It basically still works when I run it on my Mac, but this is not how it's intended, and pathnames with colons in them are invalid on Windows, so this feels like a bug. Repro is with zq commit 59b4bcc.
In a discussion with @alfred-landrum and @mattnibs it was decided that we're going to add support for S3 URL in $ZAR_ROOT, so closing this one as "invalid".
When verifying #881, I mistakenly thought I was supposed to set my
$ZAR_ROOT
to an actual S3 URL, but this is incorrect. I was supposed to still use a$ZAR_ROOT
on the local filesystem and specify the S3 URL via-data
.When I did it the wrong way, it actually accepted this and populated the bucket, but put the metadata in a local path starting with a directory
s3:
. It basically still works when I run it on my Mac, but this is not how it's intended, and pathnames with colons in them are invalid on Windows, so this feels like a bug. Repro is withzq
commit59b4bcc
.Per a team discussion today, it sounds like the fix would be to reject the S3 URL in
$ZAR_ROOT
with a helpful error message.