bgilbert commented 7 years ago

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1576.1.0
VERSION_ID=1576.1.0
BUILD_ID=2017-10-26-0503
PRETTY_NAME="Container Linux by CoreOS 1576.1.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

GCE

Reproduction Steps

gsutil cp gs://stable.release.core-os.net/amd64-usr/current/version.txt .

Expected Behavior

version.txt appears in the current directory.

Actual Behavior

version.txt is copied into a container, which is then deleted.

Other Information

The gsutil alias, as implemented, may create more confusion than value. Perhaps it should be dropped.

euank commented 7 years ago

Note, some gsutil commands will work (such as gsutil cat gs://...version.txt > version.txt

That being said, I'd be in favor of dropping it with a reasonable notice period. It's just an alias, users can fairly easily create it themselves if they wish.

houglum commented 6 years ago

Hi, I'm one of the gsutil maintainers. Just wanted to add a quick thought here.

Even if you choose to keep this alias such that it executes gsutil within a container, I think printing out that fact before running it would eliminate (or at least reduce) user confusion. In the issues linked below, users were confused as to why they didn't have access to their host filesystem; they simply weren't aware it was running in an isolated container. E.g. prepending something like echo "Creating container to run gsutil inside of..."; to the alias would have provided useful insight in these cases.

coreos / bugs

gsutil alias on GCE doesn't have access to local paths #2235